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