> -----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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
