Arjan van de Ven wrote:
but again those tools and agents *already* have a way of talking to the
hypervisor themselves. Why can't they just first ask this info? Why does
that need to be in the kernel, in unswappable memory?
Currently the two ways to get this data from user space are python via
xend, the xen control daemon, and through a C library call.
The two arguments for making some data available via sysfs are (1) to
support scripts and to (2) support efforts to slim down the required
user space tool stack.
There are alternatives for both arguments. To support scripting one
could add bindings (perl etc.) to the c library. Another alternative is
to write a succinct set of utility programs that call the c library and
invoke those utilities from scripts.
Neither of the above alternatives really help to slim down existing user
space tools, but on the other hand they don't materially add to the
problem either.
Sysfs is the simplest way to expose this info to user space. As an 8k
module it is pretty small. It fits well with convention because Xen
support is driver-like in the current linux patches. I think a xen sysfs
module is a reasonable solution. However I understand and agree with the
desire to keep unnecessary code out of the kernel.
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
