[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC] Cleaning up /proc/xen



Steven Hand wrote:

Is this going to make having udev a requirement? (or would we also mknod
some entries in de as part of an install?)

I guess most distros have had udev for a while.

Yes - though it'd be good to fix udev start (which takes ages, at least
on redhat root filesystems).
Yes, we already have some troubles here though. We're relying on reserved local-use major/minors for /dev/evtchn. We need to either register official LANA numbers for /dev/evtchn (in which case, we can just use some of minors for these other devices), or switch to using random major/minors and rely on udev.

We can't just mknod at install time--the majors/minors would be random. We'd have to read /proc/modules and attempt to figure out which ones our devices were assigned.

For non-udev systems, I think we should just take major/minor parameters as module parameters and let the users deal with figuring out what reserved numbers to use.

We have a few options for /proc/xen/balloon.  We could:
1) Get rid of it completely--not sure it's a good idea but=20
it's been suggested since it's redundant (in dom0 at least).
2) Move it to /proc/sys/
3) Move it to /sys/xen
I can't decide between 2 and 3.

There's also 0 = leave it as is.

What's the motivation for this clean-up again?
I think the reasoning is that /proc is more or less a deprecated interface. Plus, the {evtchn,grant,xenbus} interfaces are empty files that ioctls are done on--there's not really what proc files are meant to do.

Perhaps someone a bit closer to the kernel community can comment more definitively.

BTW: Anthony, as regards you directory re-organisation patch, should we
be taking the opportunity to add a version prefix e.g.
/usr/lib64/xen-3.0/bin  ?
(also, does your patch use /usr/lib64/xen on x86_64 OK?)
I'll resubmit making sure to explicitly use /usr/lib64. Hadn't considered that.

I like the idea of versioning.  I'll also include that.

I wander whether /etc/xen/scripts would be better off living under
/usr/lib/xen-3.0/scripts ?
I think that makes sense. Users aren't really supposed to modify them right? They're really more like plugins..

Should the default place to look for config file be /usr/lib/xen-3.0/etc
which is normally soft linked on install to /etc/xen ?
That seems a little awkward to me, but not too crazy. Any one else have thoughts?

I think the above three changes would enable you to have 3.0 and 2.0
tools installed in both x86_64 and x86_32 flavours all at the same time.

Hmm - how would we get the relevant python bits picked up?
This is a really good point.

We already set the path explicitly in tools/misc/{xend,xm} so that's pretty reasonable (we can expose version info to everything else through there). The only problem is how to you install the xend and xm commands for 32 and 64 in a single /usr/bin?

I think what we really need to do is have proper prefix support. That would solve the problem completely. I still think versioning the lib directory is a good idea though.

Regards,

Anthony Liguori

cheers,

S



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.