From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC] Cleaning up /proc/xen Date: Wed, 07 Sep 2005 22:24:40 -0500 Message-ID: <431FAEF8.5090801@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Steven Hand Cc: Ian Pratt , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 > > >