Re: [Xen-devel] [PATCH 5/6] libxl: introduce libxl__alloc_vdev

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 2 Apr 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 5/6] libxl: introduce 
> libxl__alloc_vdev"):
> > On Fri, 30 Mar 2012, Ian Jackson wrote:
> > > Since we need to be able to allocate some vbds dynamically, the right
> > > approach is to decree that some portion of the dom0 vbd space is
> > > reserved for static allocations by the administrator, and that the
> > > remainder is for dynamic allocations by software which picks a free
> > > vbd.  Naturally the static space should come first.
> > 
> > When you hotplug a new disk on your system, for example a new USB disk
> > to your native Linux box, usually Linux chooses the device name for
> > you. I don't see why this should be any different.
> 
> It is different because Xen vbds do in practice appear in dom0 with a
> stable name.  So this is something that people have reasonably come to
> rely on.
> 
> > The admin is going to call instead:
> >   xl block-attach 0
> > and then checkout dmesg.
> 
> This is hardly automatable.  Doing the same thing with udev rules is
> quite hard work.

I don't feel that strongly about this, but given that the naming scheme
used in the guest is actually arbitrary at the moment (as in not document
or well defined anywhere), I would start the dynamic space before the
26th device: I have the feeling that after "xvdz" the behavior is going
to be even less "defined". I suggest "xvdm" as a starting point.


> > > I don't think that is true.  On each individual guest platform, the
> > > relationship between vbd numbers (the actual interface between
> > > frontend and backend), and whatever that guest has for device names,
> > > needs to be statically defined.
> > 
> > I disagree: when we introduced docs/txt/misc/vbd-interface.txt we never
> > specified what names the guest kernel is allowed to choose for a
> > particular vbd encoding. See the following quote:
> > 
> > "The Xen interface does not specify what name a device should have in the
> > guest (nor what major/minor device number it should have in the guest,
> > if the guest has such a concept)."
> 
> This refers to the promises made by each side of the Xen VBD interface
> to the corresponding other side.  The host's environment is not
> allowed to assume things about the guest's device naming conventions.
> 
> However, that does not mean that the guest should not document its
> naming conventions.  Perhaps this needs to be clarified in the
> document.

Right, but unless I am missing something there isn't such a thing at the
moment, at least in Linux.

I'll try to come up with a linux devid to vdev function true to the
original.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel