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

Re: [Xen-devel] [PATCH] xl: (Linux) extend SCSI device name to major mapping



Jan Beulich writes ("[Xen-devel] [PATCH] xl: (Linux) extend SCSI device name to 
major mapping"):
> Rather than only permitting SCSI_DISK0_MAJOR, permit all that blkfront
> supports. However, as it is unclear to me what the meaning of major
> is on non-Linux (it seems questionable whether non-Linux, if using a
> similar major/minor concept, would happen to use major 8 as the first
> SCSI disk one), do this extension on Linux only.

I think this is wrong, I'm afraid.

Firstly, according to the document I'm trying to get agreed (see my
mail just sent, with another copy of it), sd* devices beyond disk 15
are deprecated and not supported.  You should be using xvd* if you
can.

For backwards compatibility we do support specifying the plain
xenstore number, in decimal, hex or octal.  So you can use that if you
have old guests which for some reason you can't change.

> +#ifdef __linux__

Secondly, that is entirely wrong, because that switches on the
operating system in dom0.  That may be entirely different to the
operating system in the guest.  That shows why this whole idea of
trying to specify the major/minor numbers in the guest is wrong.  Some
guests may not even _have_ major/minor numbers.

The environment provided to a Xen guest should not reference
Linux-specific numbering schemes.  For historical reasons (ie, people
having made this mistake in the past), we have to import and redefine
some existing usages.  That's what my document does.

However:

> Also, is it intentional that the /dev/ prefix (accepted by xm) is not
> accepted on the third argument by xl?

/dev doesn't make much sense once you look at it in the way I do,
above, but this should be supported for compatibility.

Ian.

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


 


Rackspace

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