Re: [Xenomai-core] /proc/xenomai broken...
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] /proc/xenomai broken...
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] /proc/xenomai broken...
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] /proc/xenomai broken...
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] /proc/xenomai broken...
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
