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

["B Thomas" <bjthomas3@xxxxxxxxx>]

Hi,

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.

fwiw,
-b

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
time.

> 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.

Jeremy

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


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

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