Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-02-03 at 15:49 +0000, Justin Gibbs wrote:
> On Feb 3, 2012, at 6:31 AM, Jan Beulich wrote:
> 
> >>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@xxxxxxxxxxxxxxxx> wrote:
> > 
> > These being mostly meaningless to non-Linux, I don't think they
> > belong here.
> > 
> > Jan
> 
> [blkif major number #defines deleted]
> 
> Front and backends must use some common convention for communicating this
> virtual device mapping.  Since Linux was the first Dom0, all blkif drivers 
> that I'm
> aware of, regardless of OS platform, reference the Linux values.

My understanding was that for BSD guests folks generally use the ability
to use a raw number as the disk spec (as referred to by the last
paragraph of "Configuration file syntax" in docs/misc/vbd-interface.txt.
However if you tell me that isn't the case in practice I'd be quite
prepared to believe you ;-)

> The mapping really only matters for HVM guests and the hand-off between a
> QEMU emulated device and the PV driver.  To avoid confusion (e.g. name of
> root mount device, device names in fstab), the PV drivers export alias 
> devices named
> to match the devices QEMU emulates.  The only way to do this successfully is 
> to
> know the major number scheme used by  Dom0/QEMU.

QEMU emulates primary and secondary IDE master+slave, it has no concept
of a major or minor number. Why does the dom0 numbering scheme matter?
(Does this relate to the old, or possibly current, xend misbehaviour of
stat()ing the dom0 device while creating a domain?)

On Linux we treat d0-d3 (however they are specified) as aliasing those 4
IDE devices (although we don't actual present alias devices but instead
use UUID or LABEL based fstab etc).

Whatever non-Linux does for weird compatibility reasons here I think the
right place to document it would be in docs/misc/vbd-interface.txt
following the precedent of the "Notes on Linux as a guest" in that
document.

Ian.


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