[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] /sys/hypervisor/uuid
On Mon, 2006-05-22 at 07:33 +0100, Keir Fraser wrote: > On 22 May 2006, at 07:21, Markus Armbruster wrote: > >> I'm personally not against the sysfs solution though, if we agree that > >> seeing your own uuid is useful at all. > > [...] > > > > How do we reach agreement (or conclude we don't)? Do we still need > > more or clearer arguments for seeing one's UUID? > > That's one problem, since nothing in the Xen tree will be making use of > this new functionality. > > The main argument seems to be about how this should be exposed to user > space. It seems reasonable to me to add this to sysfs given that we > already have a driver that exports even weirder stuff like compilation > info for Xen itself! OTOH there is absolutely no guarantee that the > xen_sysfs driver will get picked up by mainline -- there are plenty of > people who think that kind of info has no place in the guest kernel, > and they have a point. So xen_sysfs may be a dead end. And accessing xenstore from the guest kernel may also be a dead end. There are no guarantees until things get upstream which is why that is so vitally important. Then again, stability of sysfs/procfs isn't all that existent in the kernel anyway, so those who use functionality there are used to having to change it over time ;-) > If we allowed unprivileged read access to xenstore, that would require > only a smaller and more general patch to the kernel. Then you could put > the uuid extraction logic in user space? But if you still require xs transactions, then it remains complicated and a potential way to introduce fun problems for dom0 from a domU. Especially as I would expect that then people will start coding their own stuff instead of bringing a dep on libxs into domUs Jeremy _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |