RE: [RFC] Cleaning up /proc/xen

RE: [RFC] Cleaning up /proc/xen

[Ian Pratt]

 
> >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

Re: [RFC] Cleaning up /proc/xen

[Andrew Theurer]

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

RE: [RFC] Cleaning up /proc/xen

[Ian Pratt]

 
> 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/xen

I 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

RE: [RFC] Cleaning up /proc/xen

[Adam Heath]

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?

Re: [RFC] Cleaning up /proc/xen

[Steven Hand]

>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

Re: [RFC] Cleaning up /proc/xen

[Anthony Liguori]

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
>
>  
>

Re: [RFC] Cleaning up /proc/xen

[Chris Wright]

* 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.

Re: [RFC] Cleaning up /proc/xen

[Vincent Hanquez]

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

[RFC] Cleaning up /proc/xen

[Anthony Liguori]

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

Re: [RFC] Cleaning up /proc/xen

[NAHieu]

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.

Re: [RFC] Cleaning up /proc/xen

[Anthony Liguori]

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.
> 

Re: [RFC] Cleaning up /proc/xen

[Jed Davis]

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)))))

Re: [RFC] Cleaning up /proc/xen

[Daniel Stekloff]

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