linux-kernel - Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

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]

Message-ID: <20110501154751.GA14040@kroah.com>
Date:	Sun, 1 May 2011 08:47:51 -0700
From:	Greg KH <greg@...ah.com>
To:	KY Srinivasan <kys@...rosoft.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	"gregkh@...e.de" <gregkh@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>
Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

On Sun, May 01, 2011 at 11:39:21AM -0400, Christoph Hellwig wrote:
> On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> > On the host-side, as part of configuring a guest  you can specify block devices
> > as being under an IDE controller or under a
> > SCSI controller. Those are the only options you have. Devices configured under
> > the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> > the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
> > the devices enumerated will not include block devices configured under the IDE 
> > controller. So, it is not clear to me how I can do what you are proposing given the 
> > restrictions imposed by the host.
> 
> Just because a device is not reported by REPORT_LUNS doesn't mean you
> can't talk to it using a SCSI LLDD.  We have SCSI transports with all
> kinds of strange ways to discover devices.  Using scsi_add_device you
> can add LUNs found by your own discovery methods, and use all the
> existing scsi command handling.

Yeah, it seems to me that no matter how the user specifies the disk
"type" for the guest configuration, we should use the same Linux driver,
with the same naming scheme for both ways.

As Christoph points out, it's just a matter of hooking the device up to
the scsi subsystem.  We do that today for ide, usb, scsi, and loads of
other types of devices all with the common goal of making it easier for
userspace to handle the devices in a standard manner.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/