Thread (77 messages) 77 messages, 5 authors, 2011-05-02

RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

From: KY Srinivasan <kys@microsoft.com>
Date: 2011-05-01 18:57:00
Also in: lkml

-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Sunday, May 01, 2011 11:48 AM
To: KY Srinivasan
Cc: Christoph Hellwig; gregkh@suse.de; linux-kernel@vger.kernel.org;
devel@linuxdriverproject.org; virtualization@lists.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:
quoted
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
quoted
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
quoted
quoted
the IDE controller cannot be seen in the guest under the emulated SCSI front-
end which is
quoted
quoted
the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi
front-end,
quoted
quoted
the devices enumerated will not include block devices configured under the
IDE
quoted
quoted
controller. So, it is not clear to me how I can do what you are proposing given
the
quoted
quoted
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.
This is not what is being done in Xen and KVM - they both have a PV front-end
block drivers that is not managed by the scsi stack. The Hyper-V block driver is
equivalent to what we have in Xen and KVM in this respect.

Regards,

K. Y 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help