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

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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