| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home