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? 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? _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
