Today, in /proc/xen we have:
/proc/xen/balloon - displays information about memory allocations and
allows for ballooning by echoing a byte value into file
/proc/xen/privcmd - allows for userspace invocation of hypercalls and
mapping of other domains memory
/proc/xen/grant - allows grant table operations to be accessed from
userspace
/proc/xen/xenbus - allows xenbus to be accessed from userspace (in domUs)
I propose we do the following:
Change /proc/xen/{privcmd,grant,xenbus} to character devices (that use
random major/minors; we''ll always access them by name). 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
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''m partial to the last option (maybe even /sys/hypervisor/xen--that
seems to compliment /sys/firmware).
Thoughts?
Regards,
Anthony Liguori
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> I propose we do the following: > > Change /proc/xen/{privcmd,grant,xenbus} to character devices > (that use random major/minors; we''ll always access them by > name).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.> 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 > it''s been suggested since it''s redundant (in dom0 at least). > 2) Move it to /proc/sys/ > 3) Move it to /sys/xenI can''t decide between 2 and 3. 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 wander whether /etc/xen/scripts would be better off living under /usr/lib/xen-3.0/scripts ? 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 ? 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. Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 8 Sep 2005, Ian Pratt wrote:> > > I propose we do the following: > > > > Change /proc/xen/{privcmd,grant,xenbus} to character devices > > (that use random major/minors; we''ll always access them by > > name). > > 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.dynamic dev for servers is bad, mkay? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>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).>> 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?>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 wander whether /etc/xen/scripts would be better off living under >/usr/lib/xen-3.0/scripts ? > >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 ? > >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? cheers, S _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
On 9/8/05, Anthony Liguori <aliguori@us.ibm.com> wrote:> Today, in /proc/xen we have: > > /proc/xen/balloon - displays information about memory allocations and > allows for ballooning by echoing a byte value into file > > /proc/xen/privcmd - allows for userspace invocation of hypercalls and > mapping of other domains memory > > /proc/xen/grant - allows grant table operations to be accessed from > userspace > > /proc/xen/xenbus - allows xenbus to be accessed from userspace (in domUs) > > I propose we do the following: > > Change /proc/xen/{privcmd,grant,xenbus} to character devices (that use > random major/minors; we''ll always access them by name). 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 it''s been > suggested since it''s redundant (in dom0 at least). > 2) Move it to /proc/sys/ > 3) Move it to /sys/xen >The good thing about /proc is that we do not need to register any major/minor stuffs (which is very annoying), like what we do with device. So I vote for moving things to under /sys. But hold on, that would not be compatible with others OS like *BSD, correct ? Thanks, Hieu. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> >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).Yep, I''d buy a beer for whoever fixed that... Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Sep 08, 2005 at 03:51:07AM +0100, Steven Hand wrote:> >> 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?3) is the only way to get upstream -- Vincent Hanquez _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt 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). >> >> > >Yep, I''d buy a beer for whoever fixed that... > >Is this a Xen problem or just a Redhat problem? I personally noticed this when moving to 2.6.11 way back when, and I backgrounded the "$HOTPLUG scsi_device" and "$HOTPLUG scsi" lines in start_udev. For some reason hotplugging these serially would take about 30 seconds per disk, even if the disk didn''t even exist. Not sure if this is the same problem. Some (any!) debug info in start_udev would have been nice... -Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
* Anthony Liguori (aliguori@us.ibm.com) wrote:> Steven Hand wrote: > >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.Indeed.> Perhaps someone a bit closer to the kernel community can comment more > definitively.Yes, that along with basic code cleanups in drivers/xen need to be done as part of upstreaming. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2005-09-08 at 17:09 +0900, NAHieu wrote:> The good thing about /proc is that we do not need to register any > major/minor stuffs (which is very annoying), like what we do with > device.It''s much less annoying if you just don''t rely on static major/minor numbers and require udev.> So I vote for moving things to under /sys. But hold on, that would not > be compatible with others OS like *BSD, correct ?There''s also plan9 and other things to consider. I reckon it''s better to just implement first class drivers in each OS. Regards, Anthony Liguori> > Thanks, > Hieu. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2005-09-07 at 20:45 -0500, Anthony Liguori wrote:> Today, in /proc/xen we have: > > /proc/xen/balloon - displays information about memory allocations and > allows for ballooning by echoing a byte value into file > > /proc/xen/privcmd - allows for userspace invocation of hypercalls and > mapping of other domains memory > > /proc/xen/grant - allows grant table operations to be accessed from > userspace > > /proc/xen/xenbus - allows xenbus to be accessed from userspace (in domUs) > > I propose we do the following: > > Change /proc/xen/{privcmd,grant,xenbus} to character devices (that use > random major/minors; we''ll always access them by name). 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 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''m partial to the last option (maybe even /sys/hypervisor/xen--that > seems to compliment /sys/firmware). > > Thoughts?Hi Anthony, If you''re serious about option 3, it might be a good idea to post to lkml and cc the sysfs maintainer - Greg KH. He might have some suggestions. Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori <aliguori@us.ibm.com> writes:> On Thu, 2005-09-08 at 17:09 +0900, NAHieu wrote: > >> So I vote for moving things to under /sys. But hold on, that would not >> be compatible with others OS like *BSD, correct ? > > There''s also plan9 and other things to consider. I reckon it''s better > to just implement first class drivers in each OS.Even the NetBSD port changed a few interface details (e.g., /kern/xen/privcmd, because procfs is for processes only), and it''s still rather at odds with the local conventions at best. -- (let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map ((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l)))))) (lambda (f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l)) (C k))))))) ''((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline))))) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel