This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] /sys/hypervisor/uuid

To: "Jeremy Katz" <katzj@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] /sys/hypervisor/uuid
From: "B Thomas" <bjthomas3@xxxxxxxxx>
Date: Fri, 19 May 2006 09:43:08 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Markus Armbruster <armbru@xxxxxxxxxx>
Delivery-date: Fri, 19 May 2006 06:43:33 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=E04K5zrFJxC/E5RWf9kq40zYhnKLiMRGh0b7XRBICn62hSjWxRHbUXkc2XUv3e8mOaWUPq46Sz0FL+AFanyytXJUD9AS7lJstvv2dpfUsIW2P/jYgXXoZFqWjnP9Ym05NuEXLHUtS2kahRETHQEynCsE6r9dm8JJpX6kO7tHusw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1148042786.3258.28.camel@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <87y7wzmeqb.fsf@xxxxxxxxxxxxxxxxx> <446D6C68.6020102@xxxxxxxxxx> <1148042786.3258.28.camel@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

This started with a desire to get the uuid. There are a number of approaches to this issue, most are workable. Of these, I believe that full exposure of xenstore via proc or sys is the least desirable.  I feel that this approaches and perhaps crosses the "too much information" boundary.

If UUID is a desirable domU accessible item, perhaps consideration should go towards placing it into the domU SMBIOS tables that are being proposed currently on this list.  The DMI system structure has a 16 byte UUID field.  It feels like a natural place to put this type of information.


On 5/19/06, Jeremy Katz <katzj@xxxxxxxxxx> wrote:
On Fri, 2006-05-19 at 01:57 -0500, Anthony Liguori wrote:
> Markus Armbruster wrote:
> > New /sys/hypervisor/uuid, containing this domain's UUID.
> >
> > Stripping off /vm/ from the value of vm to get the UUID isn't exactly
> > nice.  The alternative is to add a XENVER_get_uuid code to
> > HYPERVISOR_xen_version(), but I'm not sure that's worth it.
> >
> > Signed-off-by: Markus Armbruster < armbru@xxxxxxxxxx>
> I really don't think we should be mirroring things in sysfs that are
> available in userspace.  What benefit is there of having two interfaces
> to the same information?

1) Ability to be used by non-privileged user
2) Relying on libxenstore being in domU is a less than ideal state
3) The kernel already has to change if the layout in xenstore changes,
userspace shouldn't have to know or care
4) The exporting of a node in procfs for accessing xenstore is crack
that will never make it upstream :)

> If the argument is that we don't want to rely on libxenstore in a domU,
> then we should be exposing all of XenStore in sysfs.

Arguably, we should[1].  But even then, I think it would be nice to have
the UUID exported in a fashion that's guaranteed to be consistent over

> The uuid parameter is a construction of Xend.  Xend is *not* a part of
> the supported guest interface.  By exposing the uuid in the kernel
> interface, you're tying an unsupported interface to what really should
> be a supported interface.

The method of where the UUID is and how it's constructed is in Xend, but
a UUID is going to always have to exist.  Even physical systems have
them.  And with good reason.

> Plus, there's already a patch floating on LKML for a /sys/hypervisor.
> We shouldn't start adding attributes to this namespace as it could
> potentially conflict with the existing patch.
> In the very least, we ought to stick this stuff in /sys/hypervisor/xen.

That, or propose it upstream in a fashion such that each hypervisor can
have it populated in its own way.  But, yeah, /sys/hypervisor/xen is
likely to be the easier way to go there.


[1] Well, or another magic debugfs -- xenstoredebugfs anyone? :)

Xen-devel mailing list

Xen-devel mailing list