linux-kernel - Re: [PATCH v2 0/2] scsi: storvsc: Add support for FC lightweight host.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 29 Jan 2017 00:56:10 -0800
From:   Christoph Hellwig <hch@...radead.org>
To:     KY Srinivasan <kys@...rosoft.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Cathy Avery <cavery@...hat.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        "jejb@...ux.vnet.ibm.com" <jejb@...ux.vnet.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "dan.carpenter@...cle.com" <dan.carpenter@...cle.com>,
        "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "famz@...hat.com" <famz@...hat.com>
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?

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?