Re: [Xen-devel] Re: [RFC] [PATCH] sysfs support for Xen attributes

From: Anthony Liguori
Date: Thu Jan 12 2006 - 10:56:30 EST


Mike D. Day wrote:

Greg KH wrote:

What other, specific sysfs files are you going to want to create?
What is the hierarchy going to look like?
What is the contents of the file going to look like?


You make a very good point. We have not agreed on the heirarchy and file contents, and we need to do so before continuing.
Some _very rough_ ideas include

/sys/xen/version/{major minor extra version build}
/sys/xen/domain/{dom0 dom1 ... domn} (each domain could be a dir. with attributes)

I don't think we want to expose domain specific information in sysfs. Right now, domain lifecycle events are managed in userspace so maintaining the kobject hierarchy here would be awkward at best.

/sys/xen/hypervisor/{scheduler cpu memory}
/sys/xen/migrate/{hosts_to, hosts_from}

Same thing as above with migration. Let's try to focus on the minimum set of things we need to expose that we cannot expose else where. There are other options (like FUSE) for providing a general filesystem management interface that we can do entirely in userspace.

I think Gerd mentioned earlier that ballooning can be exposed via the module interface--that's probably a good idea. The ioctl() interfaces should probably be misc char drivers (especially since /dev/evtchn is already).

Here's a list of the remaining things we current expose in /proc/xen that have no obvious place:

1) capabilities (is the domain a management domain)
2) xsd_mfn (a frame number for our bus so that userspace can connect to it)
3) xsd_evtchn (a virtual IRQ for xen bus for userspace)

I would think these would most obviously go under something like:

/sys/hypervisor/xen/

That would introduce a hypervisor subsystem. There are at least a few hypervisors out there already so this isn't that bad of an idea (although perhaps it may belong somewhere else in the hierarchy). Greg?

Regards,

Anthony Liguori

These will be text files with simple attrributes. Most will be read-only. It is kind of fun to think about creating a domain by doing something like

cat $domain_config > /sys/xen/domain/new

but there are some ugly aspects of doing so. Likewise it would be good to add a potential migration host by writing an ip address to
/sys/xen/migrate/hosts_to

Again, we need to get this solidified before going further.


I think this is happening as you are trying to port your code that
currently uses /proc (and file names there) to use sysfs instead, right?
To do this correctly, you need to stop thinking about file names and
paths, and start thinking about the hierarchy and relationship between
the files, which will allow you to create a tree of kobjects easier.


yes

If you answer the questions above, I think we can work to figure this
out.


Excellent, we will work on doing so.

I should be happy you didn't try to post them using Notes :)


Make that two of us :)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/