[Xen-devel] Re: [RFC PATCH 35/35] Add Xen virtual block device driver.

[Jeff Garzik <jeff@xxxxxxxxxx>]

Ian Pratt wrote:
> > This is another thing that has always put me off.  The 
> > virtual block device driver has the ability to masquerade as 
> > other types of block devices.  It actually claims to be an 
> > IDE or SCSI device allocating the appropriate major/minor numbers.
> > This seems to be pretty evil and creating interesting failure 
> > conditions for users who load IDE or SCSI modules.  I've seen 
> > it trip up a number of people in the past.  I think we should 
> > only ever use the major number that was actually allocated to us.
> We certainly should be pushing everyone toward using the 'xdX' etc
> devices that are allocated to us. However, the installers of certain
> older distros and other user space tools won't except anything other
> than hdX/sdX, so its useful from a compatibility POV even if it never
> goes into mainline, which I agree it probably shouldn't. 
Yes, this is true.  Red Hat installer guys grumbled at me when I wrote 
the 'sx8' block driver:  since it wasn't hda/sda, they had to write 
special code for it, as they apparently must do for any new block driver 
"class".  SuSE and other distros are probably similar, since each block 
driver provides its own special behaviors and feature exports.
I should have spoken up a long time ago about this, but anyway:

An IBM hypervisor on ppc64 communicates uses SCSI RPC messages.  I think 
this would be quite nice for Xen, because SCSI (a) is a message-based 
model, and (b) implementing block using SCSI has a very high Just 
Works(tm) value which cannot be ignored.  And perhaps (c) SCSI target 
code already exists, so implementing the server side doesn't require 
starting from scratch, but rather simply connecting the Legos.
        Jeff



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel