> -----Original Message----- > From: Christoph Hellwig [mailto:hch@xxxxxxxxxxxxx] > Sent: Sunday, January 29, 2017 12:56 AM > To: KY Srinivasan <kys@xxxxxxxxxxxxx> > Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Cathy Avery > <cavery@xxxxxxxxxx>; Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>; > jejb@xxxxxxxxxxxxxxxxxx; martin.petersen@xxxxxxxxxx; > dan.carpenter@xxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; famz@xxxxxxxxxx > Subject: Re: [PATCH v2 0/2] scsi: storvsc: Add support for FC lightweight host. > > On Sun, Jan 29, 2017 at 12:35:32AM +0000, KY Srinivasan wrote: > > Windows has chosen this model for virtualizing FC devices to the guest - > > without rports (or vports). As I noted in my earlier email, James came > > up with this notion of a lightweight template almost a year ago. We can > > certainly pick a more appropriate name and include better documentation. > > Can we take a step back and figure out what you're trying to > archive here. > > storsvc is a paravirtualized device interface, and whatever underlies > it should be of no relevance for the guest. > > Despite that fact Microsoft apparently wants to expose a FC-like > port_name and node_name to guests for some virtual disks. Can you > please explain what the guest is supposed to use them for? My initial implementation of the virtual FC support on Hyper-V was exactly what you are proposing here - FC disks were being treated exactly as SCSI disks. We then had customers (HP Enterprise) that were building storage appliances based on FC disks on the host and they required port name and node name information to be published in sysfs so that their management tools would work. They required the port and node ID information to be published precisely the way the FC transport would publish them (in terms of location). > > And second I'd like to understand what the fascination with the FC > transport class is to expose these two attributes. Given that > your sysfs layout will be entirely different from real FC devices > I simply don't see any need for that. > > Why can't this whole thing simply be solved by adding sdev_attrs > for the port_name and node_name to storsvc directly? No fascination with the FC transport other than it already allowed for publishing the port and node IDs. We can certainly look at other ways to publish this information - the proposal by James to have this "light weight" FC transport was precisely for this reason. Regards, K. Y _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
