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  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?

Powered by blists - more mailing lists