[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.