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


[Xen-devel] Re: [ PATCH 2.6.16-rc3-xen 3/3] sysfs: export Xen hypervisor

To: Arjan van de Ven <arjan@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [ PATCH 2.6.16-rc3-xen 3/3] sysfs: export Xen hypervisor attributes to sysfs
From: "Mike D. Day" <ncmike@xxxxxxxxxx>
Date: Wed, 22 Feb 2006 11:08:11 -0500
Cc: Dave Hansen <haveblue@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Heiko Carstens <heiko.carstens@xxxxxxxxxx>, lkml <linux-kernel@xxxxxxxxxxxxxxx>, Greg KH <greg@xxxxxxxxx>
Delivery-date: Wed, 22 Feb 2006 19:16:47 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1140616911.2979.22.camel@xxxxxxxxxxxxxxxxxxxxx>
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: <43FB2642.7020109@xxxxxxxxxx> <1140542130.8693.18.camel@xxxxxxxxxxxxxxxxxxxxx> <20060222123250.GB9295@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <43FC5B1D.5040901@xxxxxxxxxx> <1140612969.2979.20.camel@xxxxxxxxxxxxxxxxxxxxx> <43FC61C4.30002@xxxxxxxxxx> <20060222131918.GC9295@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <43FC6A86.90901@xxxxxxxxxx> <1140616911.2979.22.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (Macintosh/20051201)
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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>