| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] use case for exposing xenstore attributes via sysfs [lon
This is an argument for making every application expose an interface
through sysfs.
I think a more compelling argument to make is that there should be a
xenbusfs or perhaps a more trivial xenbus interface. If one could read
an attribute with something as simple as:
char result[1024];
fd = open("/dev/xen/xenbus", O_RDWR);
xenbus_request.path = "uuid";
xenbus_request.result = result
xenbus_request.result_len = 1024;
ioctl(fd, XENBUS_IOCREAD, &xenbus_request);
It would also solve the general problem too. There's a really
interesting article on LWN right now about sysfs being part of the Linux
userspace ABI. If we expose parts of XenStore that aren't frozen (all
of the Xend stuff which includes UUID isn't frozen) via sysfs then it
would be wrong to ever change those things.
I think you could write up a pretty simple module that provided this for
domUs. Would having a simpler kernel interface for XenBus be
acceptable? We could just change xenstore-* to use that interface and
get rid of xenstore_domain_open() (is anyone actually using this
interface anywhere else?).
Regards,
Anthony Liguori
Andrew D. Ball wrote:
I've seen some people asking why exposing xenstore attributes via sysfs
could be useful. Here's why I would really like to see such a patch
make it into Xen:
I've been working on getting domU's to know enough about themselves to
be manageable. I require a 128-bit UUID for each domU, and I require
that each domU be able to determine its own UUID in userspace. These
requirements aren't due to my trying to be difficult -- they are to ease
integration of Xen into existing system management tools. DCE UUID's
for regular hardware are very common and standardized.
Having one agreed-upon 128-bit UUID is very important to me, because I
have been working on extending some of the full virtualization code to
provide SMBIOS tables for fully virtualized domU's. Reading the SMBIOS
type 1 table is the only way that I know of for programs to find out the
UUID of the system they're running on for regular hardware, so in order
to get fully virtualized domU's to work as I expect them to, I need a
value to use for filling in the UUID in SMBIOS that everyone will be
happy with.
So, if I use the xenstore UUID for both para-virtualized and fully
virtualized domU's, I need to somehow read a para-virtualized domU's
xenstore UUID in userspace on that domU.
At the moment, I require libxenstore and libxenctrl in the domU. I read
the 'vm' xenstore attribute in the domU's xenstore home directory, which
is a string representation of the full path in xenstore to the domU's
entry in the "/vm" section of xenstore. That path includes the domU's
xenstore UUID.
libxenctrl is needed because the best way to read xenstore in userspace
on a domU at the moment involves opening /proc/xen/xenbus and doing
ioctl()'s. I do not want to do the ioctl()'s manually, without
libxenstore and libxenctrl.
Requiring libxenstore and libxenctrl is a headache, because I'm required
to get my tooling to work on SLES, and so far I see these libraries in
the same package as the rest of the xm tools. I could require users to
just install the whole xen-tools RPM, but that contains far more than
just these two libraries.
I could also just pass "uuid=<128-bit-uuid>" as an extra parameter to
the kernel and just read "/proc/cmdline" on the domU's, but I would
prefer not to make domU configurations any more complicated than
necessary.
If I could just use sysfs to read a para-virtualized domU's UUID in that
domU, my work would be considerably simpler, easier, and more elegant.
Please let me know what you think about this approach.
Andrew
=================
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home