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

[Philippe Gerum <rpm@xenomai.org>]

On 01/02/2015 08:28 PM, Jan Kiszka wrote:
> On 2015-01-02 20:31, Philippe Gerum wrote:
>> On 01/02/2015 08:15 PM, Jan Kiszka wrote:
>>> On 2015-01-02 20:20, Philippe Gerum wrote:
>>>> On 01/02/2015 07:09 PM, Jan Kiszka wrote:
>>>>> On 2015-01-02 19:07, Philippe Gerum wrote:
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Then how does the current single mount point (independent of its
>>>>> location and access rights) for all of those instances fit into this?
>>>>> Seems like they step on each other if you do not override the mount
>>>>> points on process invocation, right?
>>>>>
>>>>
>>>> Pid is used to discriminate within a session.
>>>> http://xenomai.org/migrating-from-xenomai-2-x-to-3-x/#New_FUSE-based_registry_interface
>>>
>>> So a user not specifying a session name will collide with other users
>>> this way because they all compete for anon.
>>>
>>
>> Collide on what?
> 
> Collide on managing the anon mount point. And everything that is stored
> underneath. No?
>

A sysregd instance is started each time a new session emerges, and all
processes which belong to this session will refer to this instance
exclusively for managing the hierarchy. Anon is no different.

Under the session mount point (e.g. "anon"), each process has its own
namespace. A shared branch in this hierarchy called /system is directly
attached to the session root, for all global objects shared by the session.

The anon session makes no difference compared to others, it just happens
that random processes attached there don't share any object from the
session heap.

> I'm thinking of the scenario that two unrelated but unnamed sessions are
> started, specifically by different users. In the worst case, user A
> starts off the sysregd for anon, B joins later and reuses it therfore,
> but then A decides to terminate all its processes, including the daemon.
> 

sysregd deals with such dependencies, A is not in charge of terminating
sysregd.

> Either the concept is truly multi-user capable, or we can go back to
> managing the registry daemons centrally.

How do we do this in the Mercury case where we don't want to depend on
any kernel add-on/driver for exposing internal process data, but we do
want to expose it through a file system? In addition, how do we do this
without copying data around?

-- 
Philippe.