Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point

[Philippe Gerum <rpm@xenomai.org>]

On 01/02/2015 04:59 PM, Jan Kiszka wrote:
> On 2015-01-02 16:06, Gilles Chanteperdrix wrote:
>> To explain a bit more completely. We can not assume that xenomai
>> applications are running as root user. And non root user are not
>> allowed to create /run/xenomai or /var/run/xenomai (at least not on
>> debian or slackware). What is more, these directories being
>> typically non persistent, a script has to be modified somewhere to
>> add mkdir /var/run/xenomai at every boot. On the other hand, mkdir
>> /mnt/xenomai has to be done once and only once, in the "make
>> install" phase for instance, since "make install" is run as root,
>> except that if /mnt is read-only it will not work. But not many
>> users are running system where they compile and run things with root
>> filesystem read-only. Anyway, the two cases are really similar, no
>> one is advantageous over the other. We are going to see questions on
>> the mailing list about that, whatever we do. Perhaps adding a small
>> kernel module to create /proc/xenomai/registry would make things
>> simpler...
>>
> 
> Non-root users are indeed an interesting new aspect. However, the
> solution to make a central directory writable seems weird to me. If you
> want to allow non-root users to access the registry, it would be way
> more logical to either shoot up a single privileged sysregd that
> everyone can talk to or use private instances that also run against
> their own per-user mount points, likely located in $HOME.
> 

Technically, sysregd does not have access to all the registry data, I
mean not system-wide. The registry fs is a per-session resource based on
FUSE. In shared processing mode (--enable-pshared), any number of
processes may belong to a single session, forming one application.

One sysregd instance controls the registry mount point for all processes
which belong to a single session, and also exports global information
about that session (all threads, all heaps etc). In short, it is in
charge of maintaining the fs hierarchy for one Xenomai session.

Within the session, each process exports the active objects it knows
locally about also via a FUSE-based fs, rooted within the hierarchy
maintained by sysregd.

In this discussion, we cannot assume a global sysregd instance dealing
with every possible export from every Xenomai process, that won't work.

-- 
Philippe.