[Xenomai-core] /proc/xenomai broken...

[Xenomai-core] /proc/xenomai broken...

[Gilles Chanteperdrix]

When using xenomai trunk, it appears that /proc/xenomai is no longer a
directory but a file returning "0".

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] /proc/xenomai broken...

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> When using xenomai trunk, it appears that /proc/xenomai is no longer a
> directory but a file returning "0".
> 

Check your recent changes for giving the nucleus a regular syscall 
table. I would not be surprised of some side-effect there. i.e. 
something going on with the xnptree_t descriptor?

-- 

Philippe.

Re: [Xenomai-core] /proc/xenomai broken...

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > Gilles Chanteperdrix wrote:
 > > When using xenomai trunk, it appears that /proc/xenomai is no longer a
 > > directory but a file returning "0".
 > > 
 > 
 > Check your recent changes for giving the nucleus a regular syscall 
 > table. I would not be surprised of some side-effect there. i.e. 
 > something going on with the xnptree_t descriptor?

That is exactly the source of the problem, since iface_proc_root in
nucleus/module.c has not yet been set, the proc entry for the nucleus
interface get created directly under /proc instead of
/proc/xenomai/interfaces.

Do we need a /proc entry for this interface ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] /proc/xenomai broken...

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > Gilles Chanteperdrix wrote:
>  > > When using xenomai trunk, it appears that /proc/xenomai is no longer a
>  > > directory but a file returning "0".
>  > > 
>  > 
>  > Check your recent changes for giving the nucleus a regular syscall 
>  > table. I would not be surprised of some side-effect there. i.e. 
>  > something going on with the xnptree_t descriptor?
> 
> That is exactly the source of the problem, since iface_proc_root in
> nucleus/module.c has not yet been set, the proc entry for the nucleus
> interface get created directly under /proc instead of
> /proc/xenomai/interfaces.
> 
> Do we need a /proc entry for this interface ?
> 

Not really. This would only give the exact number of processes bound to 
the nucleus, whilst major interface counters already display the number 
of bound threads.

-- 

Philippe.

Re: [Xenomai-core] /proc/xenomai broken...

[Philippe Gerum]

Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> 
>> Philippe Gerum wrote:
>>  > Gilles Chanteperdrix wrote:
>>  > > When using xenomai trunk, it appears that /proc/xenomai is no 
>> longer a
>>  > > directory but a file returning "0".
>>  > >  >  > Check your recent changes for giving the nucleus a regular 
>> syscall  > table. I would not be surprised of some side-effect there. 
>> i.e.  > something going on with the xnptree_t descriptor?
>>
>> That is exactly the source of the problem, since iface_proc_root in
>> nucleus/module.c has not yet been set, the proc entry for the nucleus
>> interface get created directly under /proc instead of
>> /proc/xenomai/interfaces.
>>
>> Do we need a /proc entry for this interface ?
>>
> 
> Not really. This would only give the exact number of processes bound to 
> the nucleus, whilst major interface counters already display the number 
> of bound threads.
> 

This said, the other option would be to move the call to 
xnshadow_mount() from the xnarch_init() to __xeno_sys_init() in a 
kernel-only section, just after xnpod_init_proc() has returned. There is 
nothing done in the arch-layer for any architecture that would prevent 
this. Btw, I'd say that "core" would be better than "xenomai" to name 
this internal interface.

-- 

Philippe.

Re: [Xenomai-core] /proc/xenomai broken...

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > This said, the other option would be to move the call to 
 > xnshadow_mount() from the xnarch_init() to __xeno_sys_init() in a 
 > kernel-only section, just after xnpod_init_proc() has returned. There is 
 > nothing done in the arch-layer for any architecture that would prevent 
 > this. Btw, I'd say that "core" would be better than "xenomai" to name 
 > this internal interface.

Ok for renaming. But no thread is ever bound to this interface, so the
count is always 0. 

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] /proc/xenomai broken...

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > This said, the other option would be to move the call to 
>  > xnshadow_mount() from the xnarch_init() to __xeno_sys_init() in a 
>  > kernel-only section, just after xnpod_init_proc() has returned. There is 
>  > nothing done in the arch-layer for any architecture that would prevent 
>  > this. Btw, I'd say that "core" would be better than "xenomai" to name 
>  > this internal interface.
> 
> Ok for renaming. But no thread is ever bound to this interface, so the
> count is always 0. 
> 

xnshadow_sys_bind()/unbind() would be the proper place to track a 
cumulated count. I'm not sure that this is going to be that useful now, 
but at some point in the future, maybe we could get a benefit from 
having a uniform way of talking to any interface using procfs, including 
to the core one.

-- 

Philippe.

Re: [Xenomai-core] /proc/xenomai broken...

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > Gilles Chanteperdrix wrote:
 > > Philippe Gerum wrote:
 > >  > This said, the other option would be to move the call to 
 > >  > xnshadow_mount() from the xnarch_init() to __xeno_sys_init() in a 
 > >  > kernel-only section, just after xnpod_init_proc() has returned. There is 
 > >  > nothing done in the arch-layer for any architecture that would prevent 
 > >  > this. Btw, I'd say that "core" would be better than "xenomai" to name 
 > >  > this internal interface.
 > > 
 > > Ok for renaming. But no thread is ever bound to this interface, so the
 > > count is always 0. 
 > > 
 > 
 > xnshadow_sys_bind()/unbind() would be the proper place to track a 
 > cumulated count. I'm not sure that this is going to be that useful now, 
 > but at some point in the future, maybe we could get a benefit from 
 > having a uniform way of talking to any interface using procfs, including 
 > to the core one.

Commit 1205 does what you suggested.

-- 


					    Gilles Chanteperdrix.