[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] /sys/hypervisor/uuid
- To: "Jeremy Katz" <katzj@xxxxxxxxxx>
- 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=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
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
|