WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] /sys/hypervisor/uuid
From: Jeremy Katz <katzj@xxxxxxxxxx>
Date: Fri, 19 May 2006 08:46:26 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Markus Armbruster <armbru@xxxxxxxxxx>
Delivery-date: Fri, 19 May 2006 05:46:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <446D6C68.6020102@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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