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

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:greg@xxxxxxxxx]
> Sent: Sunday, May 01, 2011 11:48 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx
> 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.

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 

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