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

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

[Jan Kiszka]

On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
> Module: xenomai-3
> Branch: next
> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
> 
> Author: Philippe Gerum <rpm@xenomai.org>
> Date:   Thu Jan  1 18:15:36 2015 +0100
> 
> copperplate: add configuration tunable for registry moint point
> 
> --enable-registry[=/registry-mount-point]
> 
> Defaults to /mnt/xenomai.

Do we really have to leave this as default? Then at least the debian
rules must be fixed to use a FHS-conforming path for distributed packages.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/b6cefdbb/attachment.sig>

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

[Philippe Gerum]

On 01/02/2015 11:28 AM, Jan Kiszka wrote:
> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
>> Module: xenomai-3
>> Branch: next
>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
>>
>> Author: Philippe Gerum <rpm@xenomai.org>
>> Date:   Thu Jan  1 18:15:36 2015 +0100
>>
>> copperplate: add configuration tunable for registry moint point
>>
>> --enable-registry[=/registry-mount-point]
>>
>> Defaults to /mnt/xenomai.
> 
> Do we really have to leave this as default? Then at least the debian
> rules must be fixed to use a FHS-conforming path for distributed packages.
> 

I don't care about which default is picked, really. I would agree with
both options equally, i.e. using /mnt or /var/run, since /mnt has been a
sensible and documented root for temporary mount points for ages in the
*nix world, although I find /var/run a reasonable choice for
non-persistent mount points as well.

However, there does not seem to be a consensus on this issue among other
maintainers, therefore I'm going for backward compatibility with early
x3 code some people have been running for two years now, keeping /mnt.

The patch I have issued allows to override this default using a
configuration switch, so that everyone can define this path statically
at build time.

If people eventually come to a consensus on a different but still
reasonable default value before the last -rc is released, I'll be glad
to merge it.

-- 
Philippe.

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

[Jan Kiszka]

On 2015-01-02 11:58, Philippe Gerum wrote:
> On 01/02/2015 11:28 AM, Jan Kiszka wrote:
>> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
>>> Module: xenomai-3
>>> Branch: next
>>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
>>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
>>>
>>> Author: Philippe Gerum <rpm@xenomai.org>
>>> Date:   Thu Jan  1 18:15:36 2015 +0100
>>>
>>> copperplate: add configuration tunable for registry moint point
>>>
>>> --enable-registry[=/registry-mount-point]
>>>
>>> Defaults to /mnt/xenomai.
>>
>> Do we really have to leave this as default? Then at least the debian
>> rules must be fixed to use a FHS-conforming path for distributed packages.
>>
> 
> I don't care about which default is picked, really. I would agree with
> both options equally, i.e. using /mnt or /var/run, since /mnt has been a
> sensible and documented root for temporary mount points for ages in the
> *nix world, although I find /var/run a reasonable choice for
> non-persistent mount points as well.

As I explained (and I wasn't alone with this view), this is not a matter
of taste but standard compliance: FHS requires us - as soon as we
consider Xenomai being part of the platform and not some self-written
admin script - to keep away from /mnt. You would have a hard time
finding a distro package that writes to /mnt without being explicitly
told by the admin.

> 
> However, there does not seem to be a consensus on this issue among other
> maintainers, therefore I'm going for backward compatibility with early

CC'ing the one that disagreed.

> x3 code some people have been running for two years now, keeping /mnt.
> 
> The patch I have issued allows to override this default using a
> configuration switch, so that everyone can define this path statically
> at build time.

Right, users who already have scripts based on /mnt can still configure
that path - their choice. BTW, do you have data on how many would be
affected and to which degree?

But now we are about to set this mistake in stone for everyone by
releasing 3.0 with this default. I predict that we will see prepackaged
Xenomai with different mount points. And once there are third-party
applications relying on this, it will lead to an unpleasant inconsistency.

Also, if the mount point is part of the Xenomai ABI and is now
configurable, it should probably also be discoverable for applications.

> 
> If people eventually come to a consensus on a different but still
> reasonable default value before the last -rc is released, I'll be glad
> to merge it.
> 

That's what we should try to achieve, indeed.

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/c18ddac1/attachment.sig>

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

[Gilles Chanteperdrix]

On Fri, Jan 02, 2015 at 12:11:13PM +0100, Jan Kiszka wrote:
> On 2015-01-02 11:58, Philippe Gerum wrote:
> > On 01/02/2015 11:28 AM, Jan Kiszka wrote:
> >> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
> >>> Module: xenomai-3
> >>> Branch: next
> >>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
> >>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
> >>>
> >>> Author: Philippe Gerum <rpm@xenomai.org>
> >>> Date:   Thu Jan  1 18:15:36 2015 +0100
> >>>
> >>> copperplate: add configuration tunable for registry moint point
> >>>
> >>> --enable-registry[=/registry-mount-point]
> >>>
> >>> Defaults to /mnt/xenomai.
> >>
> >> Do we really have to leave this as default? Then at least the debian
> >> rules must be fixed to use a FHS-conforming path for distributed packages.
> >>
> > 
> > I don't care about which default is picked, really. I would agree with
> > both options equally, i.e. using /mnt or /var/run, since /mnt has been a
> > sensible and documented root for temporary mount points for ages in the
> > *nix world, although I find /var/run a reasonable choice for
> > non-persistent mount points as well.
> 
> As I explained (and I wasn't alone with this view), this is not a matter
> of taste but standard compliance: FHS requires us - as soon as we
> consider Xenomai being part of the platform and not some self-written
> admin script - to keep away from /mnt. You would have a hard time
> finding a distro package that writes to /mnt without being explicitly
> told by the admin.

And as I explained, the standard sucks. /mnt on the distro I use
contains the following directories:

cdrecorder
cdrom
dvd
floppy
hd
memory
tmp
zip                 

and it puts the following text in /mnt/README

The purpose of the /mnt directory is to provide a place for the admin to
mount block device temporarily.  Any of the subdirectories of /mnt may be
used, or volumes may even be mounted directly on /mnt (which is the
traditional way of doing things, though /mnt/tmp is also provided for
the purpose of mounting any kind of volume temporarily).

See the /media directory also.

IOW: it leaves the choice to the user. What Philippe does is exactly
the same: let the user choose whether he want to use the non
standard sotlution that does not suck and that use to be a standard
practice in Linux world, or the standard solution that sucks.

I thought we agreed this was a sensible solution.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 173 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/395319e1/attachment.sig>

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

[Gilles Chanteperdrix]

On Fri, Jan 02, 2015 at 12:11:13PM +0100, Jan Kiszka wrote:
> On 2015-01-02 11:58, Philippe Gerum wrote:
> > On 01/02/2015 11:28 AM, Jan Kiszka wrote:
> >> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
> >>> Module: xenomai-3
> >>> Branch: next
> >>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
> >>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
> >>>
> >>> Author: Philippe Gerum <rpm@xenomai.org>
> >>> Date:   Thu Jan  1 18:15:36 2015 +0100
> >>>
> >>> copperplate: add configuration tunable for registry moint point
> >>>
> >>> --enable-registry[=/registry-mount-point]
> >>>
> >>> Defaults to /mnt/xenomai.
> >>
> >> Do we really have to leave this as default? Then at least the debian
> >> rules must be fixed to use a FHS-conforming path for distributed packages.
> >>
> > 
> > I don't care about which default is picked, really. I would agree with
> > both options equally, i.e. using /mnt or /var/run, since /mnt has been a
> > sensible and documented root for temporary mount points for ages in the
> > *nix world, although I find /var/run a reasonable choice for
> > non-persistent mount points as well.
> 
> As I explained (and I wasn't alone with this view), this is not a matter
> of taste but standard compliance: FHS requires us - as soon as we
> consider Xenomai being part of the platform and not some self-written
> admin script - to keep away from /mnt. You would have a hard time
> finding a distro package that writes to /mnt without being explicitly
> told by the admin.
> 

Also, there are other places where Xenomai does not conform to
standards that suck. For instance, we do not implement
PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER, which put us
clearly in violation of the POSIX standard. And this is a violation
which as more consequences on users porting code to Xenomai.
Nevertheless I never heard anybody complain about it. So, I am still
puzzled to see that we are again discussing about something as
inconsequential as god damn mount point.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 173 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/9d547495/attachment.sig>

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

[Jan Kiszka]

On 2015-01-02 13:51, Gilles Chanteperdrix wrote:
> On Fri, Jan 02, 2015 at 12:11:13PM +0100, Jan Kiszka wrote:
>> On 2015-01-02 11:58, Philippe Gerum wrote:
>>> On 01/02/2015 11:28 AM, Jan Kiszka wrote:
>>>> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
>>>>> Module: xenomai-3
>>>>> Branch: next
>>>>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
>>>>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
>>>>>
>>>>> Author: Philippe Gerum <rpm@xenomai.org>
>>>>> Date:   Thu Jan  1 18:15:36 2015 +0100
>>>>>
>>>>> copperplate: add configuration tunable for registry moint point
>>>>>
>>>>> --enable-registry[=/registry-mount-point]
>>>>>
>>>>> Defaults to /mnt/xenomai.
>>>>
>>>> Do we really have to leave this as default? Then at least the debian
>>>> rules must be fixed to use a FHS-conforming path for distributed packages.
>>>>
>>>
>>> I don't care about which default is picked, really. I would agree with
>>> both options equally, i.e. using /mnt or /var/run, since /mnt has been a
>>> sensible and documented root for temporary mount points for ages in the
>>> *nix world, although I find /var/run a reasonable choice for
>>> non-persistent mount points as well.
>>
>> As I explained (and I wasn't alone with this view), this is not a matter
>> of taste but standard compliance: FHS requires us - as soon as we
>> consider Xenomai being part of the platform and not some self-written
>> admin script - to keep away from /mnt. You would have a hard time
>> finding a distro package that writes to /mnt without being explicitly
>> told by the admin.
> 
> And as I explained, the standard sucks. /mnt on the distro I use

Even if it sucked, it remains the standard that most distros apply.

> contains the following directories:

This is apparently an exception. Debian, Ubuntu, Suse/SLES, Fedora/RHEL,
Gentoo - they all handle this conformingly and leave /mnt empty when
installing things. At least today, I cannot comment on the history of
all of them: Suse does as long as I us it (almost 20 years), Debian at
least for the past 10 years. This is my concern.

> 
> cdrecorder
> cdrom
> dvd
> floppy
> hd
> memory
> tmp
> zip                 
> 
> and it puts the following text in /mnt/README
> 
> The purpose of the /mnt directory is to provide a place for the admin to
> mount block device temporarily.  Any of the subdirectories of /mnt may be
> used, or volumes may even be mounted directly on /mnt (which is the
> traditional way of doing things, though /mnt/tmp is also provided for
> the purpose of mounting any kind of volume temporarily).
> 
> See the /media directory also.
> 
> IOW: it leaves the choice to the user. What Philippe does is exactly
> the same: let the user choose whether he want to use the non
> standard sotlution that does not suck and that use to be a standard
> practice in Linux world, or the standard solution that sucks.
> 
> I thought we agreed this was a sensible solution.

No, we didn't agree on the default behavior yet, ie. the one that users
see if they don't dig into the details and willingly deviate from FHS.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/118df1de/attachment.sig>

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

[Jan Kiszka]

On 2015-01-02 13:56, Gilles Chanteperdrix wrote:
> On Fri, Jan 02, 2015 at 12:11:13PM +0100, Jan Kiszka wrote:
>> On 2015-01-02 11:58, Philippe Gerum wrote:
>>> On 01/02/2015 11:28 AM, Jan Kiszka wrote:
>>>> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
>>>>> Module: xenomai-3
>>>>> Branch: next
>>>>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
>>>>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
>>>>>
>>>>> Author: Philippe Gerum <rpm@xenomai.org>
>>>>> Date:   Thu Jan  1 18:15:36 2015 +0100
>>>>>
>>>>> copperplate: add configuration tunable for registry moint point
>>>>>
>>>>> --enable-registry[=/registry-mount-point]
>>>>>
>>>>> Defaults to /mnt/xenomai.
>>>>
>>>> Do we really have to leave this as default? Then at least the debian
>>>> rules must be fixed to use a FHS-conforming path for distributed packages.
>>>>
>>>
>>> I don't care about which default is picked, really. I would agree with
>>> both options equally, i.e. using /mnt or /var/run, since /mnt has been a
>>> sensible and documented root for temporary mount points for ages in the
>>> *nix world, although I find /var/run a reasonable choice for
>>> non-persistent mount points as well.
>>
>> As I explained (and I wasn't alone with this view), this is not a matter
>> of taste but standard compliance: FHS requires us - as soon as we
>> consider Xenomai being part of the platform and not some self-written
>> admin script - to keep away from /mnt. You would have a hard time
>> finding a distro package that writes to /mnt without being explicitly
>> told by the admin.
>>
> 
> Also, there are other places where Xenomai does not conform to
> standards that suck. For instance, we do not implement
> PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER, which put us
> clearly in violation of the POSIX standard. And this is a violation
> which as more consequences on users porting code to Xenomai.

Sure, but there is at least an implementation-related reason behind it,
not just legacy naming.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/47f7dd06/attachment.sig>

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

[Jan Kiszka]

On 2015-01-02 14:29, Philippe Gerum wrote:
> On 01/02/2015 12:11 PM, Jan Kiszka wrote:
>> On 2015-01-02 11:58, Philippe Gerum wrote:
>>> On 01/02/2015 11:28 AM, Jan Kiszka wrote:
>>>> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
>>>>> Module: xenomai-3
>>>>> Branch: next
>>>>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
>>>>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
>>>>>
>>>>> Author: Philippe Gerum <rpm@xenomai.org>
>>>>> Date:   Thu Jan  1 18:15:36 2015 +0100
>>>>>
>>>>> copperplate: add configuration tunable for registry moint point
>>>>>
>>>>> --enable-registry[=/registry-mount-point]
>>>>>
>>>>> Defaults to /mnt/xenomai.
>>>>
>>>> Do we really have to leave this as default? Then at least the debian
>>>> rules must be fixed to use a FHS-conforming path for distributed packages.
>>>>
>>>
>>> I don't care about which default is picked, really. I would agree with
>>> both options equally, i.e. using /mnt or /var/run, since /mnt has been a
>>> sensible and documented root for temporary mount points for ages in the
>>> *nix world, although I find /var/run a reasonable choice for
>>> non-persistent mount points as well.
>>
>> As I explained (and I wasn't alone with this view), this is not a matter
>> of taste but standard compliance: FHS requires us - as soon as we
>> consider Xenomai being part of the platform and not some self-written
>> admin script - to keep away from /mnt. You would have a hard time
>> finding a distro package that writes to /mnt without being explicitly
>> told by the admin.
> 
> FHS 2.3 required volatile data to go to /var/run, and then Debian and
> others found out that it might not be the most usable choice, and went
> for /run+symlink to cope with legacy, until FHS 3.0 validates this
> arbitrary change eventually.
> 
> So, I'm ok with FHS, but in that particular case, FHS has been wrong for
> years it seems. I'd rather discuss about usability then. The kind of
> issues I'd like to see people discussing instead of going ballistic for
> a freaking mount point would rather be:
> 
> /var/run means tmpfs, which implies rw.
> /mnt means root fs, which might imply ro in some embedded cases.

Thanks for reminding, that was one of my initial points in the
discussion. It derives from the ideas of the standard about the usage of
those mount points.

Jan

> 
> x3 applications can mention the registry mount point to be used
> dynamically when starting up, so keeping /mnt would request ro fs users
> to either select a different mount point dynamically (e.g. to /var/run),
> or have /mnt/xenomai persistent in their read-only root fs.
> 
> It could be acceptable, or maybe there are arguments against requiring
> this. Please discuss about usability issues first and foremost.
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/cbf113e7/attachment.sig>

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

[Philippe Gerum]

On 01/02/2015 12:11 PM, Jan Kiszka wrote:
> On 2015-01-02 11:58, Philippe Gerum wrote:
>> On 01/02/2015 11:28 AM, Jan Kiszka wrote:
>>> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
>>>> Module: xenomai-3
>>>> Branch: next
>>>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
>>>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
>>>>
>>>> Author: Philippe Gerum <rpm@xenomai.org>
>>>> Date:   Thu Jan  1 18:15:36 2015 +0100
>>>>
>>>> copperplate: add configuration tunable for registry moint point
>>>>
>>>> --enable-registry[=/registry-mount-point]
>>>>
>>>> Defaults to /mnt/xenomai.
>>>
>>> Do we really have to leave this as default? Then at least the debian
>>> rules must be fixed to use a FHS-conforming path for distributed packages.
>>>
>>
>> I don't care about which default is picked, really. I would agree with
>> both options equally, i.e. using /mnt or /var/run, since /mnt has been a
>> sensible and documented root for temporary mount points for ages in the
>> *nix world, although I find /var/run a reasonable choice for
>> non-persistent mount points as well.
> 
> As I explained (and I wasn't alone with this view), this is not a matter
> of taste but standard compliance: FHS requires us - as soon as we
> consider Xenomai being part of the platform and not some self-written
> admin script - to keep away from /mnt. You would have a hard time
> finding a distro package that writes to /mnt without being explicitly
> told by the admin.

FHS 2.3 required volatile data to go to /var/run, and then Debian and
others found out that it might not be the most usable choice, and went
for /run+symlink to cope with legacy, until FHS 3.0 validates this
arbitrary change eventually.

So, I'm ok with FHS, but in that particular case, FHS has been wrong for
years it seems. I'd rather discuss about usability then. The kind of
issues I'd like to see people discussing instead of going ballistic for
a freaking mount point would rather be:

/var/run means tmpfs, which implies rw.
/mnt means root fs, which might imply ro in some embedded cases.

x3 applications can mention the registry mount point to be used
dynamically when starting up, so keeping /mnt would request ro fs users
to either select a different mount point dynamically (e.g. to /var/run),
or have /mnt/xenomai persistent in their read-only root fs.

It could be acceptable, or maybe there are arguments against requiring
this. Please discuss about usability issues first and foremost.

-- 
Philippe.

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

[Gilles Chanteperdrix]

On Fri, Jan 02, 2015 at 02:05:03PM +0100, Jan Kiszka wrote:
> On 2015-01-02 13:51, Gilles Chanteperdrix wrote:
> > On Fri, Jan 02, 2015 at 12:11:13PM +0100, Jan Kiszka wrote:
> >> On 2015-01-02 11:58, Philippe Gerum wrote:
> >>> On 01/02/2015 11:28 AM, Jan Kiszka wrote:
> >>>> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
> >>>>> Module: xenomai-3
> >>>>> Branch: next
> >>>>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
> >>>>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
> >>>>>
> >>>>> Author: Philippe Gerum <rpm@xenomai.org>
> >>>>> Date:   Thu Jan  1 18:15:36 2015 +0100
> >>>>>
> >>>>> copperplate: add configuration tunable for registry moint point
> >>>>>
> >>>>> --enable-registry[=/registry-mount-point]
> >>>>>
> >>>>> Defaults to /mnt/xenomai.
> >>>>
> >>>> Do we really have to leave this as default? Then at least the debian
> >>>> rules must be fixed to use a FHS-conforming path for distributed packages.
> >>>>
> >>>
> >>> I don't care about which default is picked, really. I would agree with
> >>> both options equally, i.e. using /mnt or /var/run, since /mnt has been a
> >>> sensible and documented root for temporary mount points for ages in the
> >>> *nix world, although I find /var/run a reasonable choice for
> >>> non-persistent mount points as well.
> >>
> >> As I explained (and I wasn't alone with this view), this is not a matter
> >> of taste but standard compliance: FHS requires us - as soon as we
> >> consider Xenomai being part of the platform and not some self-written
> >> admin script - to keep away from /mnt. You would have a hard time
> >> finding a distro package that writes to /mnt without being explicitly
> >> told by the admin.
> > 
> > And as I explained, the standard sucks. /mnt on the distro I use
> 
> Even if it sucked, it remains the standard that most distros apply.
> 
> > contains the following directories:
> 
> This is apparently an exception. Debian, Ubuntu, Suse/SLES, Fedora/RHEL,
> Gentoo - they all handle this conformingly and leave /mnt empty when
> installing things. At least today, I cannot comment on the history of
> all of them: Suse does as long as I us it (almost 20 years), Debian at
> least for the past 10 years. This is my concern.

Putting directories under /mnt does not prevent users from using
/mnt as a mount point. The distribution I use is Slackware, the
oldest Linux distribution still maintained.

Anyway, as I also already said, most people using Xenomai build it
from sources, and it is even probable that they do not use a
mainstream distribution, they rather use distributions that build
everything from sources, such as yocto or buildroot if they
integrate xenomai into a distribution at all.

And finally, as you already said, changing distribution scripts to
pass an FHS compliant directory, which could even be /run for Debian
instead of /var/run is not really complicated and will not break
anything. Keeping /mnt/xenomai as the default will avoid uselessly
surprising people which have been using Xenomai 3.x since the
beginning, and will keep happy people which find that using
directories under /mnt as mount points is fine. And as I also
already said, a lot of people are mounting their disks under
directories under /mnt, including people who administer Linux
systems for a living, and in fact, everything is made, including in
Debian, so that you can use /mnt the way you please, so, even using
/mnt/xenomai under Debian, would not break anything in Debian, it
would only be a problem for the stubborn people who want to use /mnt
as a mount point, but these people, which are the exception, can use
the configure option to pass /run as a mount point.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 173 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/dae0ef5b/attachment.sig>

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

[Jan Kiszka]

On 2015-01-02 15:02, Philippe Gerum wrote:
> On 01/02/2015 02:24 PM, Jan Kiszka wrote:
>> On 2015-01-02 14:29, Philippe Gerum wrote:
>>> On 01/02/2015 12:11 PM, Jan Kiszka wrote:
>>>> On 2015-01-02 11:58, Philippe Gerum wrote:
>>>>> On 01/02/2015 11:28 AM, Jan Kiszka wrote:
>>>>>> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
>>>>>>> Module: xenomai-3
>>>>>>> Branch: next
>>>>>>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
>>>>>>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
>>>>>>>
>>>>>>> Author: Philippe Gerum <rpm@xenomai.org>
>>>>>>> Date:   Thu Jan  1 18:15:36 2015 +0100
>>>>>>>
>>>>>>> copperplate: add configuration tunable for registry moint point
>>>>>>>
>>>>>>> --enable-registry[=/registry-mount-point]
>>>>>>>
>>>>>>> Defaults to /mnt/xenomai.
>>>>>>
>>>>>> Do we really have to leave this as default? Then at least the debian
>>>>>> rules must be fixed to use a FHS-conforming path for distributed packages.
>>>>>>
>>>>>
>>>>> I don't care about which default is picked, really. I would agree with
>>>>> both options equally, i.e. using /mnt or /var/run, since /mnt has been a
>>>>> sensible and documented root for temporary mount points for ages in the
>>>>> *nix world, although I find /var/run a reasonable choice for
>>>>> non-persistent mount points as well.
>>>>
>>>> As I explained (and I wasn't alone with this view), this is not a matter
>>>> of taste but standard compliance: FHS requires us - as soon as we
>>>> consider Xenomai being part of the platform and not some self-written
>>>> admin script - to keep away from /mnt. You would have a hard time
>>>> finding a distro package that writes to /mnt without being explicitly
>>>> told by the admin.
>>>
>>> FHS 2.3 required volatile data to go to /var/run, and then Debian and
>>> others found out that it might not be the most usable choice, and went
>>> for /run+symlink to cope with legacy, until FHS 3.0 validates this
>>> arbitrary change eventually.
>>>
>>> So, I'm ok with FHS, but in that particular case, FHS has been wrong for
>>> years it seems. I'd rather discuss about usability then. The kind of
>>> issues I'd like to see people discussing instead of going ballistic for
>>> a freaking mount point would rather be:
>>>
>>> /var/run means tmpfs, which implies rw.
>>> /mnt means root fs, which might imply ro in some embedded cases.
>>
>> Thanks for reminding, that was one of my initial points in the
>> discussion. It derives from the ideas of the standard about the usage of
>> those mount points.
>>
> 
> [...]
> 
>>> It could be acceptable, or maybe there are arguments against requiring
>>> this. Please discuss about usability issues first and foremost.
>>>
> 
> That part of the quote is important too. The fact that it departs from
> FHS is not a fundamental issue per se to me. What is important is
> whether departing is a problem for users, or transparent, or this
> improves usability.

It obviously degraded the default experience:
 - unexpected changes to /mnt
 - unneeded persistent changes as /mnt is not intended to be used for
   temporary system mount points, thus doesn't reside in tmpfs
 - conflicts on r/o file systems that hold /mnt

All that derives from a non-standard mount point choice, sorry.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/4a15ab86/attachment.sig>

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

[Philippe Gerum]

On 01/02/2015 02:24 PM, Jan Kiszka wrote:
> On 2015-01-02 14:29, Philippe Gerum wrote:
>> On 01/02/2015 12:11 PM, Jan Kiszka wrote:
>>> On 2015-01-02 11:58, Philippe Gerum wrote:
>>>> On 01/02/2015 11:28 AM, Jan Kiszka wrote:
>>>>> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
>>>>>> Module: xenomai-3
>>>>>> Branch: next
>>>>>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
>>>>>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
>>>>>>
>>>>>> Author: Philippe Gerum <rpm@xenomai.org>
>>>>>> Date:   Thu Jan  1 18:15:36 2015 +0100
>>>>>>
>>>>>> copperplate: add configuration tunable for registry moint point
>>>>>>
>>>>>> --enable-registry[=/registry-mount-point]
>>>>>>
>>>>>> Defaults to /mnt/xenomai.
>>>>>
>>>>> Do we really have to leave this as default? Then at least the debian
>>>>> rules must be fixed to use a FHS-conforming path for distributed packages.
>>>>>
>>>>
>>>> I don't care about which default is picked, really. I would agree with
>>>> both options equally, i.e. using /mnt or /var/run, since /mnt has been a
>>>> sensible and documented root for temporary mount points for ages in the
>>>> *nix world, although I find /var/run a reasonable choice for
>>>> non-persistent mount points as well.
>>>
>>> As I explained (and I wasn't alone with this view), this is not a matter
>>> of taste but standard compliance: FHS requires us - as soon as we
>>> consider Xenomai being part of the platform and not some self-written
>>> admin script - to keep away from /mnt. You would have a hard time
>>> finding a distro package that writes to /mnt without being explicitly
>>> told by the admin.
>>
>> FHS 2.3 required volatile data to go to /var/run, and then Debian and
>> others found out that it might not be the most usable choice, and went
>> for /run+symlink to cope with legacy, until FHS 3.0 validates this
>> arbitrary change eventually.
>>
>> So, I'm ok with FHS, but in that particular case, FHS has been wrong for
>> years it seems. I'd rather discuss about usability then. The kind of
>> issues I'd like to see people discussing instead of going ballistic for
>> a freaking mount point would rather be:
>>
>> /var/run means tmpfs, which implies rw.
>> /mnt means root fs, which might imply ro in some embedded cases.
> 
> Thanks for reminding, that was one of my initial points in the
> discussion. It derives from the ideas of the standard about the usage of
> those mount points.
> 

[...]

>> It could be acceptable, or maybe there are arguments against requiring
>> this. Please discuss about usability issues first and foremost.
>>

That part of the quote is important too. The fact that it departs from
FHS is not a fundamental issue per se to me. What is important is
whether departing is a problem for users, or transparent, or this
improves usability.

-- 
Philippe.

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

[Gilles Chanteperdrix]

On Fri, Jan 02, 2015 at 02:56:23PM +0100, Jan Kiszka wrote:
> On 2015-01-02 15:02, Philippe Gerum wrote:
> > On 01/02/2015 02:24 PM, Jan Kiszka wrote:
> >> On 2015-01-02 14:29, Philippe Gerum wrote:
> >>> On 01/02/2015 12:11 PM, Jan Kiszka wrote:
> >>>> On 2015-01-02 11:58, Philippe Gerum wrote:
> >>>>> On 01/02/2015 11:28 AM, Jan Kiszka wrote:
> >>>>>> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
> >>>>>>> Module: xenomai-3
> >>>>>>> Branch: next
> >>>>>>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
> >>>>>>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
> >>>>>>>
> >>>>>>> Author: Philippe Gerum <rpm@xenomai.org>
> >>>>>>> Date:   Thu Jan  1 18:15:36 2015 +0100
> >>>>>>>
> >>>>>>> copperplate: add configuration tunable for registry moint point
> >>>>>>>
> >>>>>>> --enable-registry[=/registry-mount-point]
> >>>>>>>
> >>>>>>> Defaults to /mnt/xenomai.
> >>>>>>
> >>>>>> Do we really have to leave this as default? Then at least the debian
> >>>>>> rules must be fixed to use a FHS-conforming path for distributed packages.
> >>>>>>
> >>>>>
> >>>>> I don't care about which default is picked, really. I would agree with
> >>>>> both options equally, i.e. using /mnt or /var/run, since /mnt has been a
> >>>>> sensible and documented root for temporary mount points for ages in the
> >>>>> *nix world, although I find /var/run a reasonable choice for
> >>>>> non-persistent mount points as well.
> >>>>
> >>>> As I explained (and I wasn't alone with this view), this is not a matter
> >>>> of taste but standard compliance: FHS requires us - as soon as we
> >>>> consider Xenomai being part of the platform and not some self-written
> >>>> admin script - to keep away from /mnt. You would have a hard time
> >>>> finding a distro package that writes to /mnt without being explicitly
> >>>> told by the admin.
> >>>
> >>> FHS 2.3 required volatile data to go to /var/run, and then Debian and
> >>> others found out that it might not be the most usable choice, and went
> >>> for /run+symlink to cope with legacy, until FHS 3.0 validates this
> >>> arbitrary change eventually.
> >>>
> >>> So, I'm ok with FHS, but in that particular case, FHS has been wrong for
> >>> years it seems. I'd rather discuss about usability then. The kind of
> >>> issues I'd like to see people discussing instead of going ballistic for
> >>> a freaking mount point would rather be:
> >>>
> >>> /var/run means tmpfs, which implies rw.
> >>> /mnt means root fs, which might imply ro in some embedded cases.
> >>
> >> Thanks for reminding, that was one of my initial points in the
> >> discussion. It derives from the ideas of the standard about the usage of
> >> those mount points.
> >>
> > 
> > [...]
> > 
> >>> It could be acceptable, or maybe there are arguments against requiring
> >>> this. Please discuss about usability issues first and foremost.
> >>>
> > 
> > That part of the quote is important too. The fact that it departs from
> > FHS is not a fundamental issue per se to me. What is important is
> > whether departing is a problem for users, or transparent, or this
> > improves usability.
> 
> It obviously degraded the default experience:
>  - unexpected changes to /mnt
>  - unneeded persistent changes as /mnt is not intended to be used for
>    temporary system mount points, thus doesn't reside in tmpfs

Both only for the small fractions of the users who do not routinely create
directories under /mnt.


>  - conflicts on r/o file systems that hold /mnt

This is a non issue: installing Xenomai requires doing a few things
as administrator, creating /mnt/xenomai would just be one more.
Using /var/run or /run on an embedded system that does not already
have it creates the same issue. Really, not a problem.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 173 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/b10bf2dc/attachment.sig>

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

[Lennart Sorensen]

On Fri, Jan 02, 2015 at 01:51:33PM +0100, Gilles Chanteperdrix wrote:
> And as I explained, the standard sucks. /mnt on the distro I use
> contains the following directories:
> 
> cdrecorder
> cdrom
> dvd
> floppy
> hd
> memory
> tmp
> zip                 
> 
> and it puts the following text in /mnt/README
> 
> The purpose of the /mnt directory is to provide a place for the admin to
> mount block device temporarily.  Any of the subdirectories of /mnt may be
> used, or volumes may even be mounted directly on /mnt (which is the
> traditional way of doing things, though /mnt/tmp is also provided for
> the purpose of mounting any kind of volume temporarily).
> 
> See the /media directory also.
> 
> IOW: it leaves the choice to the user. What Philippe does is exactly
> the same: let the user choose whether he want to use the non
> standard sotlution that does not suck and that use to be a standard
> practice in Linux world, or the standard solution that sucks.
> 
> I thought we agreed this was a sensible solution.

So your README file even says the traditional way is to mount on top
of /mnt, which again means /mnt/xenomai stops working if you do what it
says is traditional in the README on that system.  Good reason not to
rely on anything in /mnt

And a mount that is used by xenomai while running hardly qualifies as
temporary in the sense I believe /mnt was intended.

-- 
Len Sorensen

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

[Gilles Chanteperdrix]

On Fri, Jan 02, 2015 at 03:16:25PM +0100, Gilles Chanteperdrix wrote:
> On Fri, Jan 02, 2015 at 02:56:23PM +0100, Jan Kiszka wrote:
> > On 2015-01-02 15:02, Philippe Gerum wrote:
> > > On 01/02/2015 02:24 PM, Jan Kiszka wrote:
> > >> On 2015-01-02 14:29, Philippe Gerum wrote:
> > >>> On 01/02/2015 12:11 PM, Jan Kiszka wrote:
> > >>>> On 2015-01-02 11:58, Philippe Gerum wrote:
> > >>>>> On 01/02/2015 11:28 AM, Jan Kiszka wrote:
> > >>>>>> On 2015-01-01 18:43, xenomai-git-request@xenomai.org wrote:
> > >>>>>>> Module: xenomai-3
> > >>>>>>> Branch: next
> > >>>>>>> Commit: d351f712bc9b03d621b454b55fe3e46a0000294a
> > >>>>>>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=d351f712bc9b03d621b454b55fe3e46a0000294a
> > >>>>>>>
> > >>>>>>> Author: Philippe Gerum <rpm@xenomai.org>
> > >>>>>>> Date:   Thu Jan  1 18:15:36 2015 +0100
> > >>>>>>>
> > >>>>>>> copperplate: add configuration tunable for registry moint point
> > >>>>>>>
> > >>>>>>> --enable-registry[=/registry-mount-point]
> > >>>>>>>
> > >>>>>>> Defaults to /mnt/xenomai.
> > >>>>>>
> > >>>>>> Do we really have to leave this as default? Then at least the debian
> > >>>>>> rules must be fixed to use a FHS-conforming path for distributed packages.
> > >>>>>>
> > >>>>>
> > >>>>> I don't care about which default is picked, really. I would agree with
> > >>>>> both options equally, i.e. using /mnt or /var/run, since /mnt has been a
> > >>>>> sensible and documented root for temporary mount points for ages in the
> > >>>>> *nix world, although I find /var/run a reasonable choice for
> > >>>>> non-persistent mount points as well.
> > >>>>
> > >>>> As I explained (and I wasn't alone with this view), this is not a matter
> > >>>> of taste but standard compliance: FHS requires us - as soon as we
> > >>>> consider Xenomai being part of the platform and not some self-written
> > >>>> admin script - to keep away from /mnt. You would have a hard time
> > >>>> finding a distro package that writes to /mnt without being explicitly
> > >>>> told by the admin.
> > >>>
> > >>> FHS 2.3 required volatile data to go to /var/run, and then Debian and
> > >>> others found out that it might not be the most usable choice, and went
> > >>> for /run+symlink to cope with legacy, until FHS 3.0 validates this
> > >>> arbitrary change eventually.
> > >>>
> > >>> So, I'm ok with FHS, but in that particular case, FHS has been wrong for
> > >>> years it seems. I'd rather discuss about usability then. The kind of
> > >>> issues I'd like to see people discussing instead of going ballistic for
> > >>> a freaking mount point would rather be:
> > >>>
> > >>> /var/run means tmpfs, which implies rw.
> > >>> /mnt means root fs, which might imply ro in some embedded cases.
> > >>
> > >> Thanks for reminding, that was one of my initial points in the
> > >> discussion. It derives from the ideas of the standard about the usage of
> > >> those mount points.
> > >>
> > > 
> > > [...]
> > > 
> > >>> It could be acceptable, or maybe there are arguments against requiring
> > >>> this. Please discuss about usability issues first and foremost.
> > >>>
> > > 
> > > That part of the quote is important too. The fact that it departs from
> > > FHS is not a fundamental issue per se to me. What is important is
> > > whether departing is a problem for users, or transparent, or this
> > > improves usability.
> > 
> > It obviously degraded the default experience:
> >  - unexpected changes to /mnt
> >  - unneeded persistent changes as /mnt is not intended to be used for
> >    temporary system mount points, thus doesn't reside in tmpfs
> 
> Both only for the small fractions of the users who do not routinely create
> directories under /mnt.
> 
> 
> >  - conflicts on r/o file systems that hold /mnt
> 
> This is a non issue: installing Xenomai requires doing a few things
> as administrator, creating /mnt/xenomai would just be one more.
> Using /var/run or /run on an embedded system that does not already
> have it creates the same issue. Really, not a problem.

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

-- 
					    Gilles.

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

[Gilles Chanteperdrix]

On Fri, Jan 02, 2015 at 10:05:03AM -0500, Lennart Sorensen wrote:
> On Fri, Jan 02, 2015 at 01:51:33PM +0100, Gilles Chanteperdrix wrote:
> > And as I explained, the standard sucks. /mnt on the distro I use
> > contains the following directories:
> > 
> > cdrecorder
> > cdrom
> > dvd
> > floppy
> > hd
> > memory
> > tmp
> > zip                 
> > 
> > and it puts the following text in /mnt/README
> > 
> > The purpose of the /mnt directory is to provide a place for the admin to
> > mount block device temporarily.  Any of the subdirectories of /mnt may be
> > used, or volumes may even be mounted directly on /mnt (which is the
> > traditional way of doing things, though /mnt/tmp is also provided for
> > the purpose of mounting any kind of volume temporarily).
> > 
> > See the /media directory also.
> > 
> > IOW: it leaves the choice to the user. What Philippe does is exactly
> > the same: let the user choose whether he want to use the non
> > standard sotlution that does not suck and that use to be a standard
> > practice in Linux world, or the standard solution that sucks.
> > 
> > I thought we agreed this was a sensible solution.
> 
> So your README file even says the traditional way is to mount on top
> of /mnt, which again means /mnt/xenomai stops working if you do what it
> says is traditional in the README on that system.  Good reason not to
> rely on anything in /mnt

You deliberately misread the README. It says that you may mount
under whatever directory under /mnt makes sense for you OR that if
you want, you can use /mnt. In the first case, using /mnt/xenomai
will not break anything, in the second case yes, it will break
things. But as I already said, I believe not many users are using
the second solution because it inconvenient: if you do that, you
have only one mount point for temporary thing, so the standard
decided for you that you only mount one temporary thing at a time. I
do not know about you, but I sometimes need to mount more than one
thing temporarily, which is why I have plenty directories under
/mnt.

-- 
					    Gilles.

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

[Gilles Chanteperdrix]

On Fri, Jan 02, 2015 at 04:10:27PM +0100, Gilles Chanteperdrix wrote:
> On Fri, Jan 02, 2015 at 10:05:03AM -0500, Lennart Sorensen wrote:
> > On Fri, Jan 02, 2015 at 01:51:33PM +0100, Gilles Chanteperdrix wrote:
> > > And as I explained, the standard sucks. /mnt on the distro I use
> > > contains the following directories:
> > > 
> > > cdrecorder
> > > cdrom
> > > dvd
> > > floppy
> > > hd
> > > memory
> > > tmp
> > > zip                 
> > > 
> > > and it puts the following text in /mnt/README
> > > 
> > > The purpose of the /mnt directory is to provide a place for the admin to
> > > mount block device temporarily.  Any of the subdirectories of /mnt may be
> > > used, or volumes may even be mounted directly on /mnt (which is the
> > > traditional way of doing things, though /mnt/tmp is also provided for
> > > the purpose of mounting any kind of volume temporarily).
> > > 
> > > See the /media directory also.
> > > 
> > > IOW: it leaves the choice to the user. What Philippe does is exactly
> > > the same: let the user choose whether he want to use the non
> > > standard sotlution that does not suck and that use to be a standard
> > > practice in Linux world, or the standard solution that sucks.
> > > 
> > > I thought we agreed this was a sensible solution.
> > 
> > So your README file even says the traditional way is to mount on top
> > of /mnt, which again means /mnt/xenomai stops working if you do what it
> > says is traditional in the README on that system.  Good reason not to
> > rely on anything in /mnt
> 
> You deliberately misread the README. It says that you may mount
> under whatever directory under /mnt makes sense for you OR that if
> you want, you can use /mnt. In the first case, using /mnt/xenomai
> will not break anything, in the second case yes, it will break
> things. But as I already said, I believe not many users are using
> the second solution because it inconvenient: if you do that, you
> have only one mount point for temporary thing, so the standard
> decided for you that you only mount one temporary thing at a time. I
> do not know about you, but I sometimes need to mount more than one
> thing temporarily, which is why I have plenty directories under
> /mnt.

And from a pure technical point of view, the perturbation induced by
a temporary mount on /mnt will be well, temporary, as soon as you
unmount, you will be able to access /mnt/xenomai again. And I doubt
the application itself will notice anything, as it will have kept
the /mnt/xenomai directory opened and so will be able to keep
accessing it, even if something else is mounted on top of /mnt.

-- 
					    Gilles.

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

[Lennart Sorensen]

On Fri, Jan 02, 2015 at 04:22:45PM +0100, Gilles Chanteperdrix wrote:
> And from a pure technical point of view, the perturbation induced by
> a temporary mount on /mnt will be well, temporary, as soon as you
> unmount, you will be able to access /mnt/xenomai again. And I doubt
> the application itself will notice anything, as it will have kept
> the /mnt/xenomai directory opened and so will be able to keep
> accessing it, even if something else is mounted on top of /mnt.

If xenomai doesn't open and close stuff as it goes, then yes it should
stay working in that case.

I still don't consider what xenomai is doing a temporary mount though.

-- 
Len Sorensen

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

[Jan Kiszka]

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.

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/546de146/attachment.sig>

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

[Gilles Chanteperdrix]

On Fri, Jan 02, 2015 at 04:59:46PM +0100, 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.

On the other hand, users running Xenomai would likely belong to a
given group (at least, this is mandatory with cobalt), so making
xenomai mount point only writable by this group, and use the setuid
bit so that only the user who created a directory has the right to
remove it would be a simple, working solution.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 173 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/b7bdf744/attachment.sig>

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

[Gilles Chanteperdrix]

On Fri, Jan 02, 2015 at 10:47:00AM -0500, Lennart Sorensen wrote:
> On Fri, Jan 02, 2015 at 04:22:45PM +0100, Gilles Chanteperdrix wrote:
> > And from a pure technical point of view, the perturbation induced by
> > a temporary mount on /mnt will be well, temporary, as soon as you
> > unmount, you will be able to access /mnt/xenomai again. And I doubt
> > the application itself will notice anything, as it will have kept
> > the /mnt/xenomai directory opened and so will be able to keep
> > accessing it, even if something else is mounted on top of /mnt.
> 
> If xenomai doesn't open and close stuff as it goes, then yes it should
> stay working in that case.
> 
> I still don't consider what xenomai is doing a temporary mount though.

It is temporary in the sense that nothing is mounted there by fstab
or by any start script. Only xenomai applications mount and unmout
things there as they come and go.

-- 
					    Gilles.

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

[Philippe Gerum]

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.

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

[Jan Kiszka]

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?

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/e24ac14b/attachment.sig>

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

[Jan Kiszka]

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.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/0a260f13/attachment.sig>

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

[Philippe Gerum]

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

-- 
Philippe.

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

[Jan Kiszka]

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?

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.

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

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/93377ad9/attachment.sig>

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

[Philippe Gerum]

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?


-- 
Philippe.

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

[Jan Kiszka]

On 2015-01-02 20:55, Philippe Gerum wrote:
> 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.

That is not the point. If the user (or the system) decides to kill all
processes of it, it's dead. Also for user B. anon doesn't work well for
the multi-user case. It should rather be "personalized", run in a
per-user namespace.

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

This has nothing to do with kernel extensions. It's a matter of managing
central user space daemons for shared services - like shared sessions.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/459e47e9/attachment.sig>

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

[Philippe Gerum]

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.

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

[Philippe Gerum]

On 01/02/2015 08:49 PM, Jan Kiszka wrote:
> On 2015-01-02 20:55, Philippe Gerum wrote:
>> 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.
> 
> That is not the point. If the user (or the system) decides to kill all
> processes of it, it's dead. Also for user B. anon doesn't work well for
> the multi-user case. It should rather be "personalized", run in a
> per-user namespace.
> 

If the user decides to forcibly kill a central daemon it does not own,
which is not even attached its own process group anymore, then well, I'm
afraid any option will have a problem. The same way, a client process
running FUSE services won't kill the thread that serves the FUSE
requests internally.

So no, this failure scenario makes no sense. It is no different than
asking sysregd to be resilient to machine shutdown.

>>
>>> 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?
> 
> This has nothing to do with kernel extensions. It's a matter of managing
> central user space daemons for shared services - like shared sessions.
> 

I noticed that you did not care about answering my basic questions about
your proposed design. The implementation is there, and works as
advertised, including for "anon". Nothing more than advertised, nothing
less. And of course, yes it does make a lot of sense to ask about the
intervention of some central code in the kernel or not. You seem to be
Cobalt-centric in your reasoning: fair enough, but the same
implementation has to work when we don't provide any kernel bits too.

I understand you are looking for a killer argument to make your point
about changing /mnt to /var/run, which seems to imply now that you would
want the entire registry to be rewritten, for the sake of making your
argument fly.

If you think sysregd is badly designed or implemented after actual
testing, please come with facts, but doing so in a separate discussion
would likely have more impact.

-- 
Philippe.

[Xenomai] registry daemon mangement (was: Re: [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point)

[Jan Kiszka]

On 2015-01-02 21:18, Philippe Gerum wrote:
>>>> 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.
>>
>> That is not the point. If the user (or the system) decides to kill all
>> processes of it, it's dead. Also for user B. anon doesn't work well for
>> the multi-user case. It should rather be "personalized", run in a
>> per-user namespace.
>>
> 
> If the user decides to forcibly kill a central daemon it does not own,
> which is not even attached its own process group anymore, then well, I'm
> afraid any option will have a problem. The same way, a client process
> running FUSE services won't kill the thread that serves the FUSE
> requests internally.

Actually, the user doesn't have to run amok: Try starting a xenomai
process that forks off the daemon, then log out from the very same
session - bang, the daemon is killed. Independent of parallel users.

But even if that would work, letting a user-instantiated daemon manage a
system-wide resource (the anon session) is a design mistake IMHO. This
only works reliably as long as *all* users behave coordinated and
carefully. That should be avoided if somehow possible.

> 
> So no, this failure scenario makes no sense. It is no different than
> asking sysregd to be resilient to machine shutdown.

If the machine shuts down, all the users of the daemon are dead anyway -
what is your point? But that is not true if only a single user
terminates something, willingly or unwillingly.

> 
>>>
>>>> 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?
>>
>> This has nothing to do with kernel extensions. It's a matter of managing
>> central user space daemons for shared services - like shared sessions.
>>
> 
> I noticed that you did not care about answering my basic questions about
> your proposed design. The implementation is there, and works as
> advertised, including for "anon". Nothing more than advertised, nothing
> less. And of course, yes it does make a lot of sense to ask about the
> intervention of some central code in the kernel or not. You seem to be
> Cobalt-centric in your reasoning: fair enough, but the same
> implementation has to work when we don't provide any kernel bits too.

Here we are discussing the design of the sysregd user space daemon.
Please explain how the kernel influences which user runs the daemon (and
where it puts its fuse mounts)? I'm really not looking into cobalt
aspects here.

> 
> I understand you are looking for a killer argument to make your point
> about changing /mnt to /var/run, which seems to imply now that you would
> want the entire registry to be rewritten, for the sake of making your
> argument fly.

This is clearly over-interpreting my point. Gilles brought up the topic
of mulit-user scenarios, and that made me think about mount-point
unrelated aspects of the daemon. I renamed the thread therefore.

> 
> If you think sysregd is badly designed or implemented after actual
> testing, please come with facts, but doing so in a separate discussion
> would likely have more impact.

That there is one corner remaining which is not yet round doesn't make
the whole design bad - where did I say this?

BTW, your change that kicked off this thread broke the registry-enabled
build. I've pushed a fix.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/4b01c063/attachment.sig>

Re: [Xenomai] registry daemon mangement (was: Re: [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point)

[Gilles Chanteperdrix]

On Fri, Jan 02, 2015 at 11:05:23PM +0100, Jan Kiszka wrote:
> On 2015-01-02 21:18, Philippe Gerum wrote:
> > I understand you are looking for a killer argument to make your point
> > about changing /mnt to /var/run, which seems to imply now that you would
> > want the entire registry to be rewritten, for the sake of making your
> > argument fly.
> 
> This is clearly over-interpreting my point. Gilles brought up the topic
> of mulit-user scenarios, and that made me think about mount-point
> unrelated aspects of the daemon. I renamed the thread therefore.

I brought the topic of people using Xenomai as non root user, the
point I was trying to make is that using /var/run/xenomai was not
much of an improvement compared to using /mnt/xenomai. I think I was
the one to bring FHS as well, so, that is two mistakes for me.

I do not think multi-user scenarios are that problematic either: who
has several untrusted users on the system using xenomai anyway? As
has been said multiple times already, xenomai has never been audited
for security, so, if you do not trust your users, you should not let
them run xenomai applications.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 173 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150102/ab3023ce/attachment.sig>

Re: [Xenomai] registry daemon mangement

[Philippe Gerum]

On 01/02/2015 11:05 PM, Jan Kiszka wrote:
> On 2015-01-02 21:18, Philippe Gerum wrote:
>>>>> 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.
>>>
>>> That is not the point. If the user (or the system) decides to kill all
>>> processes of it, it's dead. Also for user B. anon doesn't work well for
>>> the multi-user case. It should rather be "personalized", run in a
>>> per-user namespace.
>>>
>>
>> If the user decides to forcibly kill a central daemon it does not own,
>> which is not even attached its own process group anymore, then well, I'm
>> afraid any option will have a problem. The same way, a client process
>> running FUSE services won't kill the thread that serves the FUSE
>> requests internally.
> 
> Actually, the user doesn't have to run amok: Try starting a xenomai
> process that forks off the daemon, then log out from the very same
> session - bang, the daemon is killed. Independent of parallel users.
> 

setsid().

> But even if that would work, letting a user-instantiated daemon manage a
> system-wide resource (the anon session) is a design mistake IMHO. This
> only works reliably as long as *all* users behave coordinated and
> carefully. That should be avoided if somehow possible.
> 

This is not how sysregd works.

>>
>> So no, this failure scenario makes no sense. It is no different than
>> asking sysregd to be resilient to machine shutdown.
> 
> If the machine shuts down, all the users of the daemon are dead anyway -
> what is your point? But that is not true if only a single user
> terminates something, willingly or unwillingly.
> 

I'm using this comparison because sysregd will never exit, unless the
user forcibly kills this process: this is a daemon, fork+setsid. Killing
this process deliberately and expecting the apps to behave properly
would be as silly as starting a shutdown expecting any app to be
resilient to this action. Or maybe comparing this to killing gvfsd, or
the X server, or the dbus server would make my point clearer.

>>
>>>>
>>>>> 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?
>>>
>>> This has nothing to do with kernel extensions. It's a matter of managing
>>> central user space daemons for shared services - like shared sessions.
>>>
>>
>> I noticed that you did not care about answering my basic questions about
>> your proposed design. The implementation is there, and works as
>> advertised, including for "anon". Nothing more than advertised, nothing
>> less. And of course, yes it does make a lot of sense to ask about the
>> intervention of some central code in the kernel or not. You seem to be
>> Cobalt-centric in your reasoning: fair enough, but the same
>> implementation has to work when we don't provide any kernel bits too.
> 
> Here we are discussing the design of the sysregd user space daemon.
> Please explain how the kernel influences which user runs the daemon (and
> where it puts its fuse mounts)? I'm really not looking into cobalt
> aspects here.

- when an application starts, it looks for a sysregd daemon serving its
session, or spawns one if none. Alternatively, one could start sysregd
manually from the shell before launching the application as well.
- sysregd daemonizes, no controlling terminal.
- sysregd creates the main mount point if not present:
/mount-point/<session-name>, then waits for clients on a local domain
socket named after the session.
- some client process connects to the socket endpoint.
- sysregd extracts the client pid from the peer credentials, then
creates a client sub-root within the name space:
/mount-point/<session-name>/<pid>, tells the client about its dedicated
per-process mount point, then listens to I/O events on this socket.
- client mounts its fuse-based fs on the specified directory, for
exporting the registry info it owns. The registry for this client's
data/objects is therefore served by a thread which belongs to this client.

When the client exits for whatever reason, sysregd detects the close
event on the socket, then forcibly umounts the fuse-fs hierarchy mounted
by the client, so that we don't have stale registry branches in the tree
(fusermount -u).

So, it's decentralized enough to make sure that a process will only
cause its own data to become stale upon exit, nothing more. No more
process, no more resources available from this process, nothing valuable
to export from this process. Fair enough.

With respect to the design issues:

- the same implementation works with Cobalt and Mercury. A common option
for centralizing registry services would be to rely on a component
living in kernel space, just like 2.6 does, simply because the resources
to be exposed are maintained there in the legacy architecture. With 3.x,
most of the exportable data is created and maintained in userland, so
asking people running a native kernel to push a dedicated kernel module
only for dealing with a centralized registry is not an option. We
certainly can do this from userland, and FUSE provides a way to keep the
file system semantics for this.

- we don't need to move data around each time a state change happens, to
reflect it into the registry. Instead, each client process which wants
to export data serves them using FUSE. To be even more specific about
this issue, in the "anon" case, clients rooted under this session don't
share anything, so what is displayed comes directly from their own local
memory. I'd rather not broadcast changes to portions of that memory, but
deliver it directly upon request. I'd rather not force all applications
to maintain all their data into a single system-wide heap, where a
central daemon could peek at.

- sysregd is only performing limited housekeeping chores to keep the
overall hierarchy tidy as processes come and go. If sysregd dies for any
given session, including anon, the fuse-based mount point for each
process is still there, and the registry data from clients is still
accessible. One would only lose the /system hierarchy giving access to
general information about the session which is maintained by sysregd
directly, any attempt to access it would just fail gracefully with a
"Transport endpoint is not connected" error. The running
application/processes would be unaffected.

So, although there may be other designs possible for sure, I don't see
any shortcoming in the current implementation that would lead to a
general failure when either an application or sysregd - or even both of
them - exit.

> 
>>
>> I understand you are looking for a killer argument to make your point
>> about changing /mnt to /var/run, which seems to imply now that you would
>> want the entire registry to be rewritten, for the sake of making your
>> argument fly.
> 
> This is clearly over-interpreting my point. Gilles brought up the topic
> of mulit-user scenarios, and that made me think about mount-point
> unrelated aspects of the daemon. I renamed the thread therefore.
> 
>>
>> If you think sysregd is badly designed or implemented after actual
>> testing, please come with facts, but doing so in a separate discussion
>> would likely have more impact.
> 
> That there is one corner remaining which is not yet round doesn't make
> the whole design bad - where did I say this?
> 
> BTW, your change that kicked off this thread broke the registry-enabled
> build. I've pushed a fix.
> 

Thanks, I fixed it locally too. I'll push the whole thing with -rc3
along with the new pipeline patches.

-- 
Philippe.

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

[Gilles Chanteperdrix]

On Fri, Jan 02, 2015 at 04:59:46PM +0100, 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.

The solution which works for every case is to add a boot script
which:

- creates the mount point (and ignore failure if the system is
read-only, as it is then the responsibility of whoever creates the
file system to create the mount point, ignore also failure if the
mount point already exists);

- mount a tmpfs on the mount point if the file system is read-only,
and fail if the mount point does not exist

- change the directory permission to allow all users of the e.g.
xenomai group to write to this directory.

Alternatively (to the last item), the sysregd could be made suid
root, create the session directory if it does not exist with root
permissions but with the target user as owner, then drop root
privileges and continue as a normal user.

-- 
					    Gilles.

Re: [Xenomai] registry daemon mangement

[Jan Kiszka]

On 2015-01-03 19:36, Philippe Gerum wrote:
> On 01/02/2015 11:05 PM, Jan Kiszka wrote:
>> On 2015-01-02 21:18, Philippe Gerum wrote:
>>>>>> 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.
>>>>
>>>> That is not the point. If the user (or the system) decides to kill all
>>>> processes of it, it's dead. Also for user B. anon doesn't work well for
>>>> the multi-user case. It should rather be "personalized", run in a
>>>> per-user namespace.
>>>>
>>>
>>> If the user decides to forcibly kill a central daemon it does not own,
>>> which is not even attached its own process group anymore, then well, I'm
>>> afraid any option will have a problem. The same way, a client process
>>> running FUSE services won't kill the thread that serves the FUSE
>>> requests internally.
>>
>> Actually, the user doesn't have to run amok: Try starting a xenomai
>> process that forks off the daemon, then log out from the very same
>> session - bang, the daemon is killed. Independent of parallel users.
>>
> 
> setsid().

Yep, fixes that. Will provide a patch.

> 
>> But even if that would work, letting a user-instantiated daemon manage a
>> system-wide resource (the anon session) is a design mistake IMHO. This
>> only works reliably as long as *all* users behave coordinated and
>> carefully. That should be avoided if somehow possible.
>>
> 
> This is not how sysregd works.

Then we must be talking about different things here. Which daemons do
you know that provide system-wide services are started on behalf of its
user?

> 
>>>
>>> So no, this failure scenario makes no sense. It is no different than
>>> asking sysregd to be resilient to machine shutdown.
>>
>> If the machine shuts down, all the users of the daemon are dead anyway -
>> what is your point? But that is not true if only a single user
>> terminates something, willingly or unwillingly.
>>
> 
> I'm using this comparison because sysregd will never exit, unless the
> user forcibly kills this process: this is a daemon, fork+setsid. Killing
> this process deliberately and expecting the apps to behave properly
> would be as silly as starting a shutdown expecting any app to be
> resilient to this action. Or maybe comparing this to killing gvfsd, or
> the X server, or the dbus server would make my point clearer.

dbus is a good example. As you know, there are two types of daemon
instances: those that serve specific sessions (which are per-user, thus
the daemon runs under its control) and the one that serves a central
resource, the system bus. The latter is not created on demand but
properly started as a system service.

All I'm proposing here is to follow this common pattern also for the
central service "anon session" with sysregd. We should just provide - as
reference when needed - some script (or systemd config) to kick off a
central instance for this particular session daemon in case multi-user
Xenomai operation is desired. That script - or the daemon itself when
giving some parameter - would also be able to adjust access rights to
the session mount points.

But there is more work required to make sysregd compatible with
unprivileged operation. I just tried it, and it generated various errors
here. Need to dig into them later.

> 
>>>
>>>>>
>>>>>> 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?
>>>>
>>>> This has nothing to do with kernel extensions. It's a matter of managing
>>>> central user space daemons for shared services - like shared sessions.
>>>>
>>>
>>> I noticed that you did not care about answering my basic questions about
>>> your proposed design. The implementation is there, and works as
>>> advertised, including for "anon". Nothing more than advertised, nothing
>>> less. And of course, yes it does make a lot of sense to ask about the
>>> intervention of some central code in the kernel or not. You seem to be
>>> Cobalt-centric in your reasoning: fair enough, but the same
>>> implementation has to work when we don't provide any kernel bits too.
>>
>> Here we are discussing the design of the sysregd user space daemon.
>> Please explain how the kernel influences which user runs the daemon (and
>> where it puts its fuse mounts)? I'm really not looking into cobalt
>> aspects here.
> 
> - when an application starts, it looks for a sysregd daemon serving its
> session, or spawns one if none. Alternatively, one could start sysregd
> manually from the shell before launching the application as well.
> - sysregd daemonizes, no controlling terminal.
> - sysregd creates the main mount point if not present:
> /mount-point/<session-name>, then waits for clients on a local domain
> socket named after the session.
> - some client process connects to the socket endpoint.
> - sysregd extracts the client pid from the peer credentials, then
> creates a client sub-root within the name space:
> /mount-point/<session-name>/<pid>, tells the client about its dedicated
> per-process mount point, then listens to I/O events on this socket.
> - client mounts its fuse-based fs on the specified directory, for
> exporting the registry info it owns. The registry for this client's
> data/objects is therefore served by a thread which belongs to this client.
> 
> When the client exits for whatever reason, sysregd detects the close
> event on the socket, then forcibly umounts the fuse-fs hierarchy mounted
> by the client, so that we don't have stale registry branches in the tree
> (fusermount -u).
> 
> So, it's decentralized enough to make sure that a process will only
> cause its own data to become stale upon exit, nothing more. No more
> process, no more resources available from this process, nothing valuable
> to export from this process. Fair enough.

Yep, looks good.

> 
> With respect to the design issues:
> 
> - the same implementation works with Cobalt and Mercury. A common option
> for centralizing registry services would be to rely on a component
> living in kernel space, just like 2.6 does, simply because the resources
> to be exposed are maintained there in the legacy architecture. With 3.x,
> most of the exportable data is created and maintained in userland, so
> asking people running a native kernel to push a dedicated kernel module
> only for dealing with a centralized registry is not an option. We
> certainly can do this from userland, and FUSE provides a way to keep the
> file system semantics for this.

I'm not questioning this nor proposing kernel-based centralization. It's
just about centralizing the daemon for the system-wide shared anon
session when needed.

> 
> - we don't need to move data around each time a state change happens, to
> reflect it into the registry. Instead, each client process which wants
> to export data serves them using FUSE. To be even more specific about
> this issue, in the "anon" case, clients rooted under this session don't
> share anything, so what is displayed comes directly from their own local
> memory. I'd rather not broadcast changes to portions of that memory, but
> deliver it directly upon request. I'd rather not force all applications
> to maintain all their data into a single system-wide heap, where a
> central daemon could peek at.

But they apparently share a single service that is backing the system
mount point at least. There seems to be no technical need for this,
though. If I'm not missing anything, every user of the anon session
could also have the mount point locally under a user-specific path. That
would remove the need for a central anon service. Am I right?

> 
> - sysregd is only performing limited housekeeping chores to keep the
> overall hierarchy tidy as processes come and go. If sysregd dies for any
> given session, including anon, the fuse-based mount point for each
> process is still there, and the registry data from clients is still
> accessible.

But it will no longer be updated as applications in this session change
or not applications join, no? The registry becomes stale.

> One would only lose the /system hierarchy giving access to
> general information about the session which is maintained by sysregd
> directly, any attempt to access it would just fail gracefully with a
> "Transport endpoint is not connected" error. The running
> application/processes would be unaffected.
> 
> So, although there may be other designs possible for sure, I don't see
> any shortcoming in the current implementation that would lead to a
> general failure when either an application or sysregd - or even both of
> them - exit.

A lost service remains a lost service, even if it may not be critical
for all its users.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150103/3a70cb84/attachment.sig>

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

[Jan Kiszka]

On 2015-01-03 20:40, Gilles Chanteperdrix wrote:
> On Fri, Jan 02, 2015 at 04:59:46PM +0100, 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.
> 
> The solution which works for every case is to add a boot script
> which:
> 
> - creates the mount point (and ignore failure if the system is
> read-only, as it is then the responsibility of whoever creates the
> file system to create the mount point, ignore also failure if the
> mount point already exists);
> 
> - mount a tmpfs on the mount point if the file system is read-only,
> and fail if the mount point does not exist
> 
> - change the directory permission to allow all users of the e.g.
> xenomai group to write to this directory.

Exactly. That would be reasonable at least for the anon session and
anything that the sysadmin would like to appear for everyone in the
Xenomai group. The users would still be free to start their own private
daemons for local sessions.

> 
> Alternatively (to the last item), the sysregd could be made suid
> root, create the session directory if it does not exist with root
> permissions but with the target user as owner, then drop root
> privileges and continue as a normal user.

Should work, but unless I stumbled over fundamental issues why sysregd
is not working as normal user right now, I don't see a technical need
for this big hammer for user-managed sessions.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150103/4278d1a0/attachment.sig>

Re: [Xenomai] registry daemon mangement

[Philippe Gerum]

On 01/03/2015 09:09 PM, Jan Kiszka wrote:
> On 2015-01-03 19:36, Philippe Gerum wrote:
>> On 01/02/2015 11:05 PM, Jan Kiszka wrote:
>>> On 2015-01-02 21:18, Philippe Gerum wrote:
>>>>>>> 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.
>>>>>
>>>>> That is not the point. If the user (or the system) decides to kill all
>>>>> processes of it, it's dead. Also for user B. anon doesn't work well for
>>>>> the multi-user case. It should rather be "personalized", run in a
>>>>> per-user namespace.
>>>>>
>>>>
>>>> If the user decides to forcibly kill a central daemon it does not own,
>>>> which is not even attached its own process group anymore, then well, I'm
>>>> afraid any option will have a problem. The same way, a client process
>>>> running FUSE services won't kill the thread that serves the FUSE
>>>> requests internally.
>>>
>>> Actually, the user doesn't have to run amok: Try starting a xenomai
>>> process that forks off the daemon, then log out from the very same
>>> session - bang, the daemon is killed. Independent of parallel users.
>>>
>>
>> setsid().
> 
> Yep, fixes that. Will provide a patch.
>

sysregd already damonizes using daemon(3), no need for extra setsid().

>>
>>> But even if that would work, letting a user-instantiated daemon manage a
>>> system-wide resource (the anon session) is a design mistake IMHO. This
>>> only works reliably as long as *all* users behave coordinated and
>>> carefully. That should be avoided if somehow possible.
>>>
>>
>> This is not how sysregd works.
> 
> Then we must be talking about different things here. Which daemons do
> you know that provide system-wide services are started on behalf of its
> user?

I really don't understand your question. I'm talking about sysregd and
the registry support and never talked about anything else in this
thread. There is no other daemon Xenomai-wise than sysregd.

> 
>>
>>>>
>>>> So no, this failure scenario makes no sense. It is no different than
>>>> asking sysregd to be resilient to machine shutdown.
>>>
>>> If the machine shuts down, all the users of the daemon are dead anyway -
>>> what is your point? But that is not true if only a single user
>>> terminates something, willingly or unwillingly.
>>>
>>
>> I'm using this comparison because sysregd will never exit, unless the
>> user forcibly kills this process: this is a daemon, fork+setsid. Killing
>> this process deliberately and expecting the apps to behave properly
>> would be as silly as starting a shutdown expecting any app to be
>> resilient to this action. Or maybe comparing this to killing gvfsd, or
>> the X server, or the dbus server would make my point clearer.
> 
> dbus is a good example. As you know, there are two types of daemon
> instances: those that serve specific sessions (which are per-user, thus
> the daemon runs under its control) and the one that serves a central
> resource, the system bus. The latter is not created on demand but
> properly started as a system service.
> 
> All I'm proposing here is to follow this common pattern also for the
> central service "anon session" with sysregd. We should just provide - as
> reference when needed - some script (or systemd config) to kick off a
> central instance for this particular session daemon in case multi-user
> Xenomai operation is desired. That script - or the daemon itself when
> giving some parameter - would also be able to adjust access rights to
> the session mount points.
> 
> But there is more work required to make sysregd compatible with
> unprivileged operation. I just tried it, and it generated various errors
> here. Need to dig into them later.
> 

sysregd must run with Xenomai application privileges since it connects
to the infrastructure.

>>
>>>>
>>>>>>
>>>>>>> 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?
>>>>>
>>>>> This has nothing to do with kernel extensions. It's a matter of managing
>>>>> central user space daemons for shared services - like shared sessions.
>>>>>
>>>>
>>>> I noticed that you did not care about answering my basic questions about
>>>> your proposed design. The implementation is there, and works as
>>>> advertised, including for "anon". Nothing more than advertised, nothing
>>>> less. And of course, yes it does make a lot of sense to ask about the
>>>> intervention of some central code in the kernel or not. You seem to be
>>>> Cobalt-centric in your reasoning: fair enough, but the same
>>>> implementation has to work when we don't provide any kernel bits too.
>>>
>>> Here we are discussing the design of the sysregd user space daemon.
>>> Please explain how the kernel influences which user runs the daemon (and
>>> where it puts its fuse mounts)? I'm really not looking into cobalt
>>> aspects here.
>>
>> - when an application starts, it looks for a sysregd daemon serving its
>> session, or spawns one if none. Alternatively, one could start sysregd
>> manually from the shell before launching the application as well.
>> - sysregd daemonizes, no controlling terminal.
>> - sysregd creates the main mount point if not present:
>> /mount-point/<session-name>, then waits for clients on a local domain
>> socket named after the session.
>> - some client process connects to the socket endpoint.
>> - sysregd extracts the client pid from the peer credentials, then
>> creates a client sub-root within the name space:
>> /mount-point/<session-name>/<pid>, tells the client about its dedicated
>> per-process mount point, then listens to I/O events on this socket.
>> - client mounts its fuse-based fs on the specified directory, for
>> exporting the registry info it owns. The registry for this client's
>> data/objects is therefore served by a thread which belongs to this client.
>>
>> When the client exits for whatever reason, sysregd detects the close
>> event on the socket, then forcibly umounts the fuse-fs hierarchy mounted
>> by the client, so that we don't have stale registry branches in the tree
>> (fusermount -u).
>>
>> So, it's decentralized enough to make sure that a process will only
>> cause its own data to become stale upon exit, nothing more. No more
>> process, no more resources available from this process, nothing valuable
>> to export from this process. Fair enough.
> 
> Yep, looks good.
> 
>>
>> With respect to the design issues:
>>
>> - the same implementation works with Cobalt and Mercury. A common option
>> for centralizing registry services would be to rely on a component
>> living in kernel space, just like 2.6 does, simply because the resources
>> to be exposed are maintained there in the legacy architecture. With 3.x,
>> most of the exportable data is created and maintained in userland, so
>> asking people running a native kernel to push a dedicated kernel module
>> only for dealing with a centralized registry is not an option. We
>> certainly can do this from userland, and FUSE provides a way to keep the
>> file system semantics for this.
> 
> I'm not questioning this nor proposing kernel-based centralization. It's
> just about centralizing the daemon for the system-wide shared anon
> session when needed.
> 

I'm under the impression that we are investing way too much time only to
end up with a script doing:

sysregd --daemon --root /foo/bar/anon

>>
>> - we don't need to move data around each time a state change happens, to
>> reflect it into the registry. Instead, each client process which wants
>> to export data serves them using FUSE. To be even more specific about
>> this issue, in the "anon" case, clients rooted under this session don't
>> share anything, so what is displayed comes directly from their own local
>> memory. I'd rather not broadcast changes to portions of that memory, but
>> deliver it directly upon request. I'd rather not force all applications
>> to maintain all their data into a single system-wide heap, where a
>> central daemon could peek at.
> 
> But they apparently share a single service that is backing the system
> mount point at least. There seems to be no technical need for this,
> though. If I'm not missing anything, every user of the anon session
> could also have the mount point locally under a user-specific path. That
> would remove the need for a central anon service. Am I right?
> 
>>
>> - sysregd is only performing limited housekeeping chores to keep the
>> overall hierarchy tidy as processes come and go. If sysregd dies for any
>> given session, including anon, the fuse-based mount point for each
>> process is still there, and the registry data from clients is still
>> accessible.
> 
> But it will no longer be updated as applications in this session change
> or not applications join, no? The registry becomes stale.

No, the fs is managed by the client process, not sysregd. sysregd will
be automatically restarted by the emerging application that discovers
than no sysregd instance is currently serving its session. Sysregd is
mainly there to keep the namespace tidy using fusermount as client
processes come and go. If it gets forcibly killed by the user, most of
the problem will entail running "fusermount -u /foo/bar/session/<pid>"
manually, which hardly qualifies as a massive issue.

> 
>> One would only lose the /system hierarchy giving access to
>> general information about the session which is maintained by sysregd
>> directly, any attempt to access it would just fail gracefully with a
>> "Transport endpoint is not connected" error. The running
>> application/processes would be unaffected.
>>
>> So, although there may be other designs possible for sure, I don't see
>> any shortcoming in the current implementation that would lead to a
>> general failure when either an application or sysregd - or even both of
>> them - exit.
> 
> A lost service remains a lost service, even if it may not be critical
> for all its users.
> 

Mmf. If one kills the X server deliberately, then he should not complain
about losing the desktop. If one kills sysregd deliberately despite this
is a _daemon_ with real-time group privileges, then he should not
complain about losing /foo/bar/session/system, and only that though.

I probably don't understand correctly the point you are trying to make,
so I'll wait for the patches.

-- 
Philippe.

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

[Gilles Chanteperdrix]

On Sat, Jan 03, 2015 at 09:17:50PM +0100, Jan Kiszka wrote:
> On 2015-01-03 20:40, Gilles Chanteperdrix wrote:
> > On Fri, Jan 02, 2015 at 04:59:46PM +0100, 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.
> > 
> > The solution which works for every case is to add a boot script
> > which:
> > 
> > - creates the mount point (and ignore failure if the system is
> > read-only, as it is then the responsibility of whoever creates the
> > file system to create the mount point, ignore also failure if the
> > mount point already exists);
> > 
> > - mount a tmpfs on the mount point if the file system is read-only,
> > and fail if the mount point does not exist
> > 
> > - change the directory permission to allow all users of the e.g.
> > xenomai group to write to this directory.
> 
> Exactly. That would be reasonable at least for the anon session and
> anything that the sysadmin would like to appear for everyone in the
> Xenomai group. The users would still be free to start their own private
> daemons for local sessions.

As far as I understood, the directory used for a session is
/mnt/xenomai/session
So, /mnt/xenomai must be writable for all sessions, not only the
anon one.

> 
> > 
> > Alternatively (to the last item), the sysregd could be made suid
> > root, create the session directory if it does not exist with root
> > permissions but with the target user as owner, then drop root
> > privileges and continue as a normal user.
> 
> Should work, but unless I stumbled over fundamental issues why sysregd
> is not working as normal user right now, I don't see a technical need
> for this big hammer for user-managed sessions.

The enormous advantage of using the big hammer (in fact, only if we
put the three changes into it), is that it avoids explaining things
to the users, and avoids as well questions on the mailing list.
Given the number of questions we have had about /dev/rtheap and
/dev/rtpipe, this would be a win.

-- 
					    Gilles.

Re: [Xenomai] registry daemon mangement

[Jan Kiszka]

On 2015-01-03 21:55, Philippe Gerum wrote:
> On 01/03/2015 09:09 PM, Jan Kiszka wrote:
>> On 2015-01-03 19:36, Philippe Gerum wrote:
>>> On 01/02/2015 11:05 PM, Jan Kiszka wrote:
>>>> On 2015-01-02 21:18, Philippe Gerum wrote:
>>>>>>>> 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.
>>>>>>
>>>>>> That is not the point. If the user (or the system) decides to kill all
>>>>>> processes of it, it's dead. Also for user B. anon doesn't work well for
>>>>>> the multi-user case. It should rather be "personalized", run in a
>>>>>> per-user namespace.
>>>>>>
>>>>>
>>>>> If the user decides to forcibly kill a central daemon it does not own,
>>>>> which is not even attached its own process group anymore, then well, I'm
>>>>> afraid any option will have a problem. The same way, a client process
>>>>> running FUSE services won't kill the thread that serves the FUSE
>>>>> requests internally.
>>>>
>>>> Actually, the user doesn't have to run amok: Try starting a xenomai
>>>> process that forks off the daemon, then log out from the very same
>>>> session - bang, the daemon is killed. Independent of parallel users.
>>>>
>>>
>>> setsid().
>>
>> Yep, fixes that. Will provide a patch.
>>
> 
> sysregd already damonizes using daemon(3), no need for extra setsid().

Indeed. But the effect remains, though it's weird.

Anyway, the actual bug was missing ignore of SIGHUP - which is sent as
soon as the original session is closed.

> 
>>>
>>>> But even if that would work, letting a user-instantiated daemon manage a
>>>> system-wide resource (the anon session) is a design mistake IMHO. This
>>>> only works reliably as long as *all* users behave coordinated and
>>>> carefully. That should be avoided if somehow possible.
>>>>
>>>
>>> This is not how sysregd works.
>>
>> Then we must be talking about different things here. Which daemons do
>> you know that provide system-wide services are started on behalf of its
>> user?
> 
> I really don't understand your question. I'm talking about sysregd and
> the registry support and never talked about anything else in this
> thread. There is no other daemon Xenomai-wise than sysregd.
> 
>>
>>>
>>>>>
>>>>> So no, this failure scenario makes no sense. It is no different than
>>>>> asking sysregd to be resilient to machine shutdown.
>>>>
>>>> If the machine shuts down, all the users of the daemon are dead anyway -
>>>> what is your point? But that is not true if only a single user
>>>> terminates something, willingly or unwillingly.
>>>>
>>>
>>> I'm using this comparison because sysregd will never exit, unless the
>>> user forcibly kills this process: this is a daemon, fork+setsid. Killing
>>> this process deliberately and expecting the apps to behave properly
>>> would be as silly as starting a shutdown expecting any app to be
>>> resilient to this action. Or maybe comparing this to killing gvfsd, or
>>> the X server, or the dbus server would make my point clearer.
>>
>> dbus is a good example. As you know, there are two types of daemon
>> instances: those that serve specific sessions (which are per-user, thus
>> the daemon runs under its control) and the one that serves a central
>> resource, the system bus. The latter is not created on demand but
>> properly started as a system service.
>>
>> All I'm proposing here is to follow this common pattern also for the
>> central service "anon session" with sysregd. We should just provide - as
>> reference when needed - some script (or systemd config) to kick off a
>> central instance for this particular session daemon in case multi-user
>> Xenomai operation is desired. That script - or the daemon itself when
>> giving some parameter - would also be able to adjust access rights to
>> the session mount points.
>>
>> But there is more work required to make sysregd compatible with
>> unprivileged operation. I just tried it, and it generated various errors
>> here. Need to dig into them later.
>>
> 
> sysregd must run with Xenomai application privileges since it connects
> to the infrastructure.

Sure, that's what I configured.

The problem seems to be related to daemonization, for whatever reason.
Starting sysregd manually (after tuning /etc/fuse.conf as required -
which could be avoided by using a central daemon) works fine if it stays
in foreground (except that it does not properly unmount on termination).
But if I push it into the background, I get

   0"049.287| WARNING: [main] can't mount registry onto
/var/run/xenomai/anon/system
   0"050.669| BUG: [main] initialization failed, EPERM

and

segfault at 7f1ef25bc000 ip 00007f1ef21014d7 sp 00007f1ef25d37b8 error 4
in libcobalt.so.2.0.0[7f1ef20f5000+1c000]
sysregd[3667]: segfault at 7f1ef25bc000 ip 00007f1ef21014d7 sp
00007f1ef25d37b8 error 4 in libcobalt.so.2.0.0[7f1ef20f5000+1c000]

on the kernel console.

> 
>>>
>>>>>
>>>>>>>
>>>>>>>> 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?
>>>>>>
>>>>>> This has nothing to do with kernel extensions. It's a matter of managing
>>>>>> central user space daemons for shared services - like shared sessions.
>>>>>>
>>>>>
>>>>> I noticed that you did not care about answering my basic questions about
>>>>> your proposed design. The implementation is there, and works as
>>>>> advertised, including for "anon". Nothing more than advertised, nothing
>>>>> less. And of course, yes it does make a lot of sense to ask about the
>>>>> intervention of some central code in the kernel or not. You seem to be
>>>>> Cobalt-centric in your reasoning: fair enough, but the same
>>>>> implementation has to work when we don't provide any kernel bits too.
>>>>
>>>> Here we are discussing the design of the sysregd user space daemon.
>>>> Please explain how the kernel influences which user runs the daemon (and
>>>> where it puts its fuse mounts)? I'm really not looking into cobalt
>>>> aspects here.
>>>
>>> - when an application starts, it looks for a sysregd daemon serving its
>>> session, or spawns one if none. Alternatively, one could start sysregd
>>> manually from the shell before launching the application as well.
>>> - sysregd daemonizes, no controlling terminal.
>>> - sysregd creates the main mount point if not present:
>>> /mount-point/<session-name>, then waits for clients on a local domain
>>> socket named after the session.
>>> - some client process connects to the socket endpoint.
>>> - sysregd extracts the client pid from the peer credentials, then
>>> creates a client sub-root within the name space:
>>> /mount-point/<session-name>/<pid>, tells the client about its dedicated
>>> per-process mount point, then listens to I/O events on this socket.
>>> - client mounts its fuse-based fs on the specified directory, for
>>> exporting the registry info it owns. The registry for this client's
>>> data/objects is therefore served by a thread which belongs to this client.
>>>
>>> When the client exits for whatever reason, sysregd detects the close
>>> event on the socket, then forcibly umounts the fuse-fs hierarchy mounted
>>> by the client, so that we don't have stale registry branches in the tree
>>> (fusermount -u).
>>>
>>> So, it's decentralized enough to make sure that a process will only
>>> cause its own data to become stale upon exit, nothing more. No more
>>> process, no more resources available from this process, nothing valuable
>>> to export from this process. Fair enough.
>>
>> Yep, looks good.
>>
>>>
>>> With respect to the design issues:
>>>
>>> - the same implementation works with Cobalt and Mercury. A common option
>>> for centralizing registry services would be to rely on a component
>>> living in kernel space, just like 2.6 does, simply because the resources
>>> to be exposed are maintained there in the legacy architecture. With 3.x,
>>> most of the exportable data is created and maintained in userland, so
>>> asking people running a native kernel to push a dedicated kernel module
>>> only for dealing with a centralized registry is not an option. We
>>> certainly can do this from userland, and FUSE provides a way to keep the
>>> file system semantics for this.
>>
>> I'm not questioning this nor proposing kernel-based centralization. It's
>> just about centralizing the daemon for the system-wide shared anon
>> session when needed.
>>
> 
> I'm under the impression that we are investing way too much time only to
> end up with a script doing:
> 
> sysregd --daemon --root /foo/bar/anon

--linger - which is broken. Fix will follow.

See, we are also shaking out remaining bugs, so that is already added
value of this discussion.

> 
>>>
>>> - we don't need to move data around each time a state change happens, to
>>> reflect it into the registry. Instead, each client process which wants
>>> to export data serves them using FUSE. To be even more specific about
>>> this issue, in the "anon" case, clients rooted under this session don't
>>> share anything, so what is displayed comes directly from their own local
>>> memory. I'd rather not broadcast changes to portions of that memory, but
>>> deliver it directly upon request. I'd rather not force all applications
>>> to maintain all their data into a single system-wide heap, where a
>>> central daemon could peek at.
>>
>> But they apparently share a single service that is backing the system
>> mount point at least. There seems to be no technical need for this,
>> though. If I'm not missing anything, every user of the anon session
>> could also have the mount point locally under a user-specific path. That
>> would remove the need for a central anon service. Am I right?
>>
>>>
>>> - sysregd is only performing limited housekeeping chores to keep the
>>> overall hierarchy tidy as processes come and go. If sysregd dies for any
>>> given session, including anon, the fuse-based mount point for each
>>> process is still there, and the registry data from clients is still
>>> accessible.
>>
>> But it will no longer be updated as applications in this session change
>> or not applications join, no? The registry becomes stale.
> 
> No, the fs is managed by the client process, not sysregd. sysregd will
> be automatically restarted by the emerging application that discovers

*Emerging* - running applications will still lose the daemon.

> than no sysregd instance is currently serving its session. Sysregd is
> mainly there to keep the namespace tidy using fusermount as client
> processes come and go. If it gets forcibly killed by the user, most of
> the problem will entail running "fusermount -u /foo/bar/session/<pid>"
> manually, which hardly qualifies as a massive issue.
> 
>>
>>> One would only lose the /system hierarchy giving access to
>>> general information about the session which is maintained by sysregd
>>> directly, any attempt to access it would just fail gracefully with a
>>> "Transport endpoint is not connected" error. The running
>>> application/processes would be unaffected.
>>>
>>> So, although there may be other designs possible for sure, I don't see
>>> any shortcoming in the current implementation that would lead to a
>>> general failure when either an application or sysregd - or even both of
>>> them - exit.
>>
>> A lost service remains a lost service, even if it may not be critical
>> for all its users.
>>
> 
> Mmf. If one kills the X server deliberately, then he should not complain
> about losing the desktop.

The difference is that this effect is limited to the user, not affecting
others on different screens, thus different X servers. Containment.

> If one kills sysregd deliberately despite this
> is a _daemon_ with real-time group privileges, then he should not
> complain about losing /foo/bar/session/system, and only that though.
> 
> I probably don't understand correctly the point you are trying to make,
> so I'll wait for the patches.
> 

Central service, central daemon. Per-user/session/whatever service,
local daemons. A standard pattern, nothing more.

I'll look into some Xenomai service script. That could also be used to
tune other parameters, specifically allowed_group.

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150104/c2660db6/attachment.sig>

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

[Jan Kiszka]

On 2015-01-03 23:25, Gilles Chanteperdrix wrote:
>>>
>>> Alternatively (to the last item), the sysregd could be made suid
>>> root, create the session directory if it does not exist with root
>>> permissions but with the target user as owner, then drop root
>>> privileges and continue as a normal user.
>>
>> Should work, but unless I stumbled over fundamental issues why sysregd
>> is not working as normal user right now, I don't see a technical need
>> for this big hammer for user-managed sessions.
> 
> The enormous advantage of using the big hammer (in fact, only if we
> put the three changes into it), is that it avoids explaining things
> to the users, and avoids as well questions on the mailing list.
> Given the number of questions we have had about /dev/rtheap and
> /dev/rtpipe, this would be a win.

We actually need the big suid-hammer: only root has the permission to
clean up the mounts of other users. Obsoletes my fusermount -u patch.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Gilles Chanteperdrix]

On Wed, Jan 07, 2015 at 07:14:56PM +0100, Jan Kiszka wrote:
> On 2015-01-03 23:25, Gilles Chanteperdrix wrote:
> >>>
> >>> Alternatively (to the last item), the sysregd could be made suid
> >>> root, create the session directory if it does not exist with root
> >>> permissions but with the target user as owner, then drop root
> >>> privileges and continue as a normal user.
> >>
> >> Should work, but unless I stumbled over fundamental issues why sysregd
> >> is not working as normal user right now, I don't see a technical need
> >> for this big hammer for user-managed sessions.
> > 
> > The enormous advantage of using the big hammer (in fact, only if we
> > put the three changes into it), is that it avoids explaining things
> > to the users, and avoids as well questions on the mailing list.
> > Given the number of questions we have had about /dev/rtheap and
> > /dev/rtpipe, this would be a win.
> 
> We actually need the big suid-hammer: only root has the permission to
> clean up the mounts of other users. Obsoletes my fusermount -u patch.

Why does root need to clean up the mounts of other users if each
user cleans up its mounts ?

-- 
					    Gilles.

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

[Jan Kiszka]

On 2015-01-12 11:42, Gilles Chanteperdrix wrote:
> On Wed, Jan 07, 2015 at 07:14:56PM +0100, Jan Kiszka wrote:
>> On 2015-01-03 23:25, Gilles Chanteperdrix wrote:
>>>>>
>>>>> Alternatively (to the last item), the sysregd could be made suid
>>>>> root, create the session directory if it does not exist with root
>>>>> permissions but with the target user as owner, then drop root
>>>>> privileges and continue as a normal user.
>>>>
>>>> Should work, but unless I stumbled over fundamental issues why sysregd
>>>> is not working as normal user right now, I don't see a technical need
>>>> for this big hammer for user-managed sessions.
>>>
>>> The enormous advantage of using the big hammer (in fact, only if we
>>> put the three changes into it), is that it avoids explaining things
>>> to the users, and avoids as well questions on the mailing list.
>>> Given the number of questions we have had about /dev/rtheap and
>>> /dev/rtpipe, this would be a win.
>>
>> We actually need the big suid-hammer: only root has the permission to
>> clean up the mounts of other users. Obsoletes my fusermount -u patch.
> 
> Why does root need to clean up the mounts of other users if each
> user cleans up its mounts ?

As long as the daemon only runs on behalf of the very same user, this
works. But this breaks when user A starts a session and B joins it or
inherits a still running daemon.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Gilles Chanteperdrix]

On Mon, Jan 12, 2015 at 12:19:20PM +0100, Jan Kiszka wrote:
> On 2015-01-12 11:42, Gilles Chanteperdrix wrote:
> > On Wed, Jan 07, 2015 at 07:14:56PM +0100, Jan Kiszka wrote:
> >> On 2015-01-03 23:25, Gilles Chanteperdrix wrote:
> >>>>>
> >>>>> Alternatively (to the last item), the sysregd could be made suid
> >>>>> root, create the session directory if it does not exist with root
> >>>>> permissions but with the target user as owner, then drop root
> >>>>> privileges and continue as a normal user.
> >>>>
> >>>> Should work, but unless I stumbled over fundamental issues why sysregd
> >>>> is not working as normal user right now, I don't see a technical need
> >>>> for this big hammer for user-managed sessions.
> >>>
> >>> The enormous advantage of using the big hammer (in fact, only if we
> >>> put the three changes into it), is that it avoids explaining things
> >>> to the users, and avoids as well questions on the mailing list.
> >>> Given the number of questions we have had about /dev/rtheap and
> >>> /dev/rtpipe, this would be a win.
> >>
> >> We actually need the big suid-hammer: only root has the permission to
> >> clean up the mounts of other users. Obsoletes my fusermount -u patch.
> > 
> > Why does root need to clean up the mounts of other users if each
> > user cleans up its mounts ?
> 
> As long as the daemon only runs on behalf of the very same user, this
> works. But this breaks when user A starts a session and B joins it or
> inherits a still running daemon.

Is it really a case that matters ? As I already said, I believe
running xenomai programs as simple user should be taken into
account, but multiple users for the same session ?

-- 
					    Gilles.

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

[Jan Kiszka]

On 2015-01-12 12:34, Gilles Chanteperdrix wrote:
> On Mon, Jan 12, 2015 at 12:19:20PM +0100, Jan Kiszka wrote:
>> On 2015-01-12 11:42, Gilles Chanteperdrix wrote:
>>> On Wed, Jan 07, 2015 at 07:14:56PM +0100, Jan Kiszka wrote:
>>>> On 2015-01-03 23:25, Gilles Chanteperdrix wrote:
>>>>>>>
>>>>>>> Alternatively (to the last item), the sysregd could be made suid
>>>>>>> root, create the session directory if it does not exist with root
>>>>>>> permissions but with the target user as owner, then drop root
>>>>>>> privileges and continue as a normal user.
>>>>>>
>>>>>> Should work, but unless I stumbled over fundamental issues why sysregd
>>>>>> is not working as normal user right now, I don't see a technical need
>>>>>> for this big hammer for user-managed sessions.
>>>>>
>>>>> The enormous advantage of using the big hammer (in fact, only if we
>>>>> put the three changes into it), is that it avoids explaining things
>>>>> to the users, and avoids as well questions on the mailing list.
>>>>> Given the number of questions we have had about /dev/rtheap and
>>>>> /dev/rtpipe, this would be a win.
>>>>
>>>> We actually need the big suid-hammer: only root has the permission to
>>>> clean up the mounts of other users. Obsoletes my fusermount -u patch.
>>>
>>> Why does root need to clean up the mounts of other users if each
>>> user cleans up its mounts ?
>>
>> As long as the daemon only runs on behalf of the very same user, this
>> works. But this breaks when user A starts a session and B joins it or
>> inherits a still running daemon.
> 
> Is it really a case that matters ? As I already said, I believe
> running xenomai programs as simple user should be taken into
> account, but multiple users for the same session ?

If that is not required, we could make the mount point private in $HOME.
Then it is clear to the user that sessions cannot be shared. And the
namespaces would be isolated automatically.

Anon will continue to require a root daemon that has to be started in
advance.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Jan Kiszka]

On 2015-01-12 15:35, Philippe Gerum wrote:
> On 01/12/2015 12:59 PM, Jan Kiszka wrote:
>> On 2015-01-12 12:34, Gilles Chanteperdrix wrote:
>>> On Mon, Jan 12, 2015 at 12:19:20PM +0100, Jan Kiszka wrote:
>>>> On 2015-01-12 11:42, Gilles Chanteperdrix wrote:
>>>>> On Wed, Jan 07, 2015 at 07:14:56PM +0100, Jan Kiszka wrote:
>>>>>> On 2015-01-03 23:25, Gilles Chanteperdrix wrote:
>>>>>>>>>
>>>>>>>>> Alternatively (to the last item), the sysregd could be made suid
>>>>>>>>> root, create the session directory if it does not exist with root
>>>>>>>>> permissions but with the target user as owner, then drop root
>>>>>>>>> privileges and continue as a normal user.
>>>>>>>>
>>>>>>>> Should work, but unless I stumbled over fundamental issues why sysregd
>>>>>>>> is not working as normal user right now, I don't see a technical need
>>>>>>>> for this big hammer for user-managed sessions.
>>>>>>>
>>>>>>> The enormous advantage of using the big hammer (in fact, only if we
>>>>>>> put the three changes into it), is that it avoids explaining things
>>>>>>> to the users, and avoids as well questions on the mailing list.
>>>>>>> Given the number of questions we have had about /dev/rtheap and
>>>>>>> /dev/rtpipe, this would be a win.
>>>>>>
>>>>>> We actually need the big suid-hammer: only root has the permission to
>>>>>> clean up the mounts of other users. Obsoletes my fusermount -u patch.
>>>>>
>>>>> Why does root need to clean up the mounts of other users if each
>>>>> user cleans up its mounts ?
>>>>
>>>> As long as the daemon only runs on behalf of the very same user, this
>>>> works. But this breaks when user A starts a session and B joins it or
>>>> inherits a still running daemon.
>>>
>>> Is it really a case that matters ? As I already said, I believe
>>> running xenomai programs as simple user should be taken into
>>> account, but multiple users for the same session ?
>>
>> If that is not required, we could make the mount point private in $HOME.
>> Then it is clear to the user that sessions cannot be shared. And the
>> namespaces would be isolated automatically.
>>
>> Anon will continue to require a root daemon that has to be started in
>> advance.
>>
> 
> Looks ok. Named sessions have been designed as a way to share things
> between processes composing a larger application, basically. Assuming
> that all processes sharing a named session must belong to the same uid
> is part of the original design.

OK, then let's sketch a design:

- if sysregd runs as non-root, it uses $HOME/.xenomai as default
  (open for alternative suggestions as well -
  DEFAULT_REGISTRY_ROOT/$USER?) registry root, otherwise
  DEFAULT_REGISTRY_ROOT. Overriding via --root remains unaffected.

- remove --shared-registry application option, only provide
  "sysregd --shared" because we need it for the anon session

- do not install sysregd with suid

Makes sense?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Philippe Gerum]

On 01/12/2015 12:59 PM, Jan Kiszka wrote:
> On 2015-01-12 12:34, Gilles Chanteperdrix wrote:
>> On Mon, Jan 12, 2015 at 12:19:20PM +0100, Jan Kiszka wrote:
>>> On 2015-01-12 11:42, Gilles Chanteperdrix wrote:
>>>> On Wed, Jan 07, 2015 at 07:14:56PM +0100, Jan Kiszka wrote:
>>>>> On 2015-01-03 23:25, Gilles Chanteperdrix wrote:
>>>>>>>>
>>>>>>>> Alternatively (to the last item), the sysregd could be made suid
>>>>>>>> root, create the session directory if it does not exist with root
>>>>>>>> permissions but with the target user as owner, then drop root
>>>>>>>> privileges and continue as a normal user.
>>>>>>>
>>>>>>> Should work, but unless I stumbled over fundamental issues why sysregd
>>>>>>> is not working as normal user right now, I don't see a technical need
>>>>>>> for this big hammer for user-managed sessions.
>>>>>>
>>>>>> The enormous advantage of using the big hammer (in fact, only if we
>>>>>> put the three changes into it), is that it avoids explaining things
>>>>>> to the users, and avoids as well questions on the mailing list.
>>>>>> Given the number of questions we have had about /dev/rtheap and
>>>>>> /dev/rtpipe, this would be a win.
>>>>>
>>>>> We actually need the big suid-hammer: only root has the permission to
>>>>> clean up the mounts of other users. Obsoletes my fusermount -u patch.
>>>>
>>>> Why does root need to clean up the mounts of other users if each
>>>> user cleans up its mounts ?
>>>
>>> As long as the daemon only runs on behalf of the very same user, this
>>> works. But this breaks when user A starts a session and B joins it or
>>> inherits a still running daemon.
>>
>> Is it really a case that matters ? As I already said, I believe
>> running xenomai programs as simple user should be taken into
>> account, but multiple users for the same session ?
> 
> If that is not required, we could make the mount point private in $HOME.
> Then it is clear to the user that sessions cannot be shared. And the
> namespaces would be isolated automatically.
> 
> Anon will continue to require a root daemon that has to be started in
> advance.
> 

Looks ok. Named sessions have been designed as a way to share things
between processes composing a larger application, basically. Assuming
that all processes sharing a named session must belong to the same uid
is part of the original design.

-- 
Philippe.

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

[Jan Kiszka]

On 2015-01-13 10:22, Philippe Gerum wrote:
> On 01/12/2015 03:34 PM, Jan Kiszka wrote:
>> On 2015-01-12 15:35, Philippe Gerum wrote:
>>> On 01/12/2015 12:59 PM, Jan Kiszka wrote:
>>>> On 2015-01-12 12:34, Gilles Chanteperdrix wrote:
>>>>> On Mon, Jan 12, 2015 at 12:19:20PM +0100, Jan Kiszka wrote:
>>>>>> On 2015-01-12 11:42, Gilles Chanteperdrix wrote:
>>>>>>> On Wed, Jan 07, 2015 at 07:14:56PM +0100, Jan Kiszka wrote:
>>>>>>>> On 2015-01-03 23:25, Gilles Chanteperdrix wrote:
>>>>>>>>>>>
>>>>>>>>>>> Alternatively (to the last item), the sysregd could be made suid
>>>>>>>>>>> root, create the session directory if it does not exist with root
>>>>>>>>>>> permissions but with the target user as owner, then drop root
>>>>>>>>>>> privileges and continue as a normal user.
>>>>>>>>>>
>>>>>>>>>> Should work, but unless I stumbled over fundamental issues why sysregd
>>>>>>>>>> is not working as normal user right now, I don't see a technical need
>>>>>>>>>> for this big hammer for user-managed sessions.
>>>>>>>>>
>>>>>>>>> The enormous advantage of using the big hammer (in fact, only if we
>>>>>>>>> put the three changes into it), is that it avoids explaining things
>>>>>>>>> to the users, and avoids as well questions on the mailing list.
>>>>>>>>> Given the number of questions we have had about /dev/rtheap and
>>>>>>>>> /dev/rtpipe, this would be a win.
>>>>>>>>
>>>>>>>> We actually need the big suid-hammer: only root has the permission to
>>>>>>>> clean up the mounts of other users. Obsoletes my fusermount -u patch.
>>>>>>>
>>>>>>> Why does root need to clean up the mounts of other users if each
>>>>>>> user cleans up its mounts ?
>>>>>>
>>>>>> As long as the daemon only runs on behalf of the very same user, this
>>>>>> works. But this breaks when user A starts a session and B joins it or
>>>>>> inherits a still running daemon.
>>>>>
>>>>> Is it really a case that matters ? As I already said, I believe
>>>>> running xenomai programs as simple user should be taken into
>>>>> account, but multiple users for the same session ?
>>>>
>>>> If that is not required, we could make the mount point private in $HOME.
>>>> Then it is clear to the user that sessions cannot be shared. And the
>>>> namespaces would be isolated automatically.
>>>>
>>>> Anon will continue to require a root daemon that has to be started in
>>>> advance.
>>>>
>>>
>>> Looks ok. Named sessions have been designed as a way to share things
>>> between processes composing a larger application, basically. Assuming
>>> that all processes sharing a named session must belong to the same uid
>>> is part of the original design.
>>
>> OK, then let's sketch a design:
>>
>> - if sysregd runs as non-root, it uses $HOME/.xenomai as default
>>   (open for alternative suggestions as well -
>>   DEFAULT_REGISTRY_ROOT/$USER?) registry root, otherwise
>>   DEFAULT_REGISTRY_ROOT. Overriding via --root remains unaffected.
> 
> $DEFAULT_REGISTRY_ROOT/$USER would align on current practices for
> dynamic mounts in other areas (e.g. removable media).
> 
>>
>> - remove --shared-registry application option, only provide
>>   "sysregd --shared" because we need it for the anon session
>>
> 
> Ok.
> 
>> - do not install sysregd with suid
>>
> 
> Definitely.
> 
>> Makes sense?
>>
> 
> Works for me.
> 

Good. Should come as replacement patches or on top of current next?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Philippe Gerum]

On 01/12/2015 03:34 PM, Jan Kiszka wrote:
> On 2015-01-12 15:35, Philippe Gerum wrote:
>> On 01/12/2015 12:59 PM, Jan Kiszka wrote:
>>> On 2015-01-12 12:34, Gilles Chanteperdrix wrote:
>>>> On Mon, Jan 12, 2015 at 12:19:20PM +0100, Jan Kiszka wrote:
>>>>> On 2015-01-12 11:42, Gilles Chanteperdrix wrote:
>>>>>> On Wed, Jan 07, 2015 at 07:14:56PM +0100, Jan Kiszka wrote:
>>>>>>> On 2015-01-03 23:25, Gilles Chanteperdrix wrote:
>>>>>>>>>>
>>>>>>>>>> Alternatively (to the last item), the sysregd could be made suid
>>>>>>>>>> root, create the session directory if it does not exist with root
>>>>>>>>>> permissions but with the target user as owner, then drop root
>>>>>>>>>> privileges and continue as a normal user.
>>>>>>>>>
>>>>>>>>> Should work, but unless I stumbled over fundamental issues why sysregd
>>>>>>>>> is not working as normal user right now, I don't see a technical need
>>>>>>>>> for this big hammer for user-managed sessions.
>>>>>>>>
>>>>>>>> The enormous advantage of using the big hammer (in fact, only if we
>>>>>>>> put the three changes into it), is that it avoids explaining things
>>>>>>>> to the users, and avoids as well questions on the mailing list.
>>>>>>>> Given the number of questions we have had about /dev/rtheap and
>>>>>>>> /dev/rtpipe, this would be a win.
>>>>>>>
>>>>>>> We actually need the big suid-hammer: only root has the permission to
>>>>>>> clean up the mounts of other users. Obsoletes my fusermount -u patch.
>>>>>>
>>>>>> Why does root need to clean up the mounts of other users if each
>>>>>> user cleans up its mounts ?
>>>>>
>>>>> As long as the daemon only runs on behalf of the very same user, this
>>>>> works. But this breaks when user A starts a session and B joins it or
>>>>> inherits a still running daemon.
>>>>
>>>> Is it really a case that matters ? As I already said, I believe
>>>> running xenomai programs as simple user should be taken into
>>>> account, but multiple users for the same session ?
>>>
>>> If that is not required, we could make the mount point private in $HOME.
>>> Then it is clear to the user that sessions cannot be shared. And the
>>> namespaces would be isolated automatically.
>>>
>>> Anon will continue to require a root daemon that has to be started in
>>> advance.
>>>
>>
>> Looks ok. Named sessions have been designed as a way to share things
>> between processes composing a larger application, basically. Assuming
>> that all processes sharing a named session must belong to the same uid
>> is part of the original design.
> 
> OK, then let's sketch a design:
> 
> - if sysregd runs as non-root, it uses $HOME/.xenomai as default
>   (open for alternative suggestions as well -
>   DEFAULT_REGISTRY_ROOT/$USER?) registry root, otherwise
>   DEFAULT_REGISTRY_ROOT. Overriding via --root remains unaffected.

$DEFAULT_REGISTRY_ROOT/$USER would align on current practices for
dynamic mounts in other areas (e.g. removable media).

> 
> - remove --shared-registry application option, only provide
>   "sysregd --shared" because we need it for the anon session
> 

Ok.

> - do not install sysregd with suid
> 

Definitely.

> Makes sense?
> 

Works for me.

-- 
Philippe.

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

[Philippe Gerum]

On 01/13/2015 10:11 AM, Jan Kiszka wrote:
> On 2015-01-13 10:22, Philippe Gerum wrote:
>> On 01/12/2015 03:34 PM, Jan Kiszka wrote:
>>> On 2015-01-12 15:35, Philippe Gerum wrote:
>>>> On 01/12/2015 12:59 PM, Jan Kiszka wrote:
>>>>> On 2015-01-12 12:34, Gilles Chanteperdrix wrote:
>>>>>> On Mon, Jan 12, 2015 at 12:19:20PM +0100, Jan Kiszka wrote:
>>>>>>> On 2015-01-12 11:42, Gilles Chanteperdrix wrote:
>>>>>>>> On Wed, Jan 07, 2015 at 07:14:56PM +0100, Jan Kiszka wrote:
>>>>>>>>> On 2015-01-03 23:25, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Alternatively (to the last item), the sysregd could be made suid
>>>>>>>>>>>> root, create the session directory if it does not exist with root
>>>>>>>>>>>> permissions but with the target user as owner, then drop root
>>>>>>>>>>>> privileges and continue as a normal user.
>>>>>>>>>>>
>>>>>>>>>>> Should work, but unless I stumbled over fundamental issues why sysregd
>>>>>>>>>>> is not working as normal user right now, I don't see a technical need
>>>>>>>>>>> for this big hammer for user-managed sessions.
>>>>>>>>>>
>>>>>>>>>> The enormous advantage of using the big hammer (in fact, only if we
>>>>>>>>>> put the three changes into it), is that it avoids explaining things
>>>>>>>>>> to the users, and avoids as well questions on the mailing list.
>>>>>>>>>> Given the number of questions we have had about /dev/rtheap and
>>>>>>>>>> /dev/rtpipe, this would be a win.
>>>>>>>>>
>>>>>>>>> We actually need the big suid-hammer: only root has the permission to
>>>>>>>>> clean up the mounts of other users. Obsoletes my fusermount -u patch.
>>>>>>>>
>>>>>>>> Why does root need to clean up the mounts of other users if each
>>>>>>>> user cleans up its mounts ?
>>>>>>>
>>>>>>> As long as the daemon only runs on behalf of the very same user, this
>>>>>>> works. But this breaks when user A starts a session and B joins it or
>>>>>>> inherits a still running daemon.
>>>>>>
>>>>>> Is it really a case that matters ? As I already said, I believe
>>>>>> running xenomai programs as simple user should be taken into
>>>>>> account, but multiple users for the same session ?
>>>>>
>>>>> If that is not required, we could make the mount point private in $HOME.
>>>>> Then it is clear to the user that sessions cannot be shared. And the
>>>>> namespaces would be isolated automatically.
>>>>>
>>>>> Anon will continue to require a root daemon that has to be started in
>>>>> advance.
>>>>>
>>>>
>>>> Looks ok. Named sessions have been designed as a way to share things
>>>> between processes composing a larger application, basically. Assuming
>>>> that all processes sharing a named session must belong to the same uid
>>>> is part of the original design.
>>>
>>> OK, then let's sketch a design:
>>>
>>> - if sysregd runs as non-root, it uses $HOME/.xenomai as default
>>>   (open for alternative suggestions as well -
>>>   DEFAULT_REGISTRY_ROOT/$USER?) registry root, otherwise
>>>   DEFAULT_REGISTRY_ROOT. Overriding via --root remains unaffected.
>>
>> $DEFAULT_REGISTRY_ROOT/$USER would align on current practices for
>> dynamic mounts in other areas (e.g. removable media).
>>
>>>
>>> - remove --shared-registry application option, only provide
>>>   "sysregd --shared" because we need it for the anon session
>>>
>>
>> Ok.
>>
>>> - do not install sysregd with suid
>>>
>>
>> Definitely.
>>
>>> Makes sense?
>>>
>>
>> Works for me.
>>
> 
> Good. Should come as replacement patches or on top of current next?
> 

-next may be rebased, I'll pick the replacement.

-- 
Philippe.