* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point [not found] <mailman.787.1420134217.6101.xenomai-git@xenomai.org> @ 2015-01-02 10:28 ` Jan Kiszka 2015-01-02 10:58 ` Philippe Gerum 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 10:28 UTC (permalink / raw) To: Philippe Gerum; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 10:28 ` [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point Jan Kiszka @ 2015-01-02 10:58 ` Philippe Gerum 2015-01-02 11:11 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-02 10:58 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 10:58 ` Philippe Gerum @ 2015-01-02 11:11 ` Jan Kiszka 2015-01-02 12:51 ` Gilles Chanteperdrix ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 11:11 UTC (permalink / raw) To: Philippe Gerum; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 11:11 ` Jan Kiszka @ 2015-01-02 12:51 ` Gilles Chanteperdrix 2015-01-02 13:05 ` Jan Kiszka 2015-01-02 15:05 ` Lennart Sorensen 2015-01-02 12:56 ` Gilles Chanteperdrix 2015-01-02 13:29 ` Philippe Gerum 2 siblings, 2 replies; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-02 12:51 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 12:51 ` Gilles Chanteperdrix @ 2015-01-02 13:05 ` Jan Kiszka 2015-01-02 13:41 ` Gilles Chanteperdrix 2015-01-02 15:05 ` Lennart Sorensen 1 sibling, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 13:05 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 13:05 ` Jan Kiszka @ 2015-01-02 13:41 ` Gilles Chanteperdrix 0 siblings, 0 replies; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-02 13:41 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 12:51 ` Gilles Chanteperdrix 2015-01-02 13:05 ` Jan Kiszka @ 2015-01-02 15:05 ` Lennart Sorensen 2015-01-02 15:10 ` Gilles Chanteperdrix 1 sibling, 1 reply; 49+ messages in thread From: Lennart Sorensen @ 2015-01-02 15:05 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Jan Kiszka, Xenomai 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 15:05 ` Lennart Sorensen @ 2015-01-02 15:10 ` Gilles Chanteperdrix 2015-01-02 15:22 ` Gilles Chanteperdrix 0 siblings, 1 reply; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-02 15:10 UTC (permalink / raw) To: Lennart Sorensen; +Cc: Jan Kiszka, Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 15:10 ` Gilles Chanteperdrix @ 2015-01-02 15:22 ` Gilles Chanteperdrix 2015-01-02 15:47 ` Lennart Sorensen 0 siblings, 1 reply; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-02 15:22 UTC (permalink / raw) To: Lennart Sorensen; +Cc: Jan Kiszka, Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 15:22 ` Gilles Chanteperdrix @ 2015-01-02 15:47 ` Lennart Sorensen 2015-01-02 18:06 ` Gilles Chanteperdrix 0 siblings, 1 reply; 49+ messages in thread From: Lennart Sorensen @ 2015-01-02 15:47 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Jan Kiszka, Xenomai 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 15:47 ` Lennart Sorensen @ 2015-01-02 18:06 ` Gilles Chanteperdrix 0 siblings, 0 replies; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-02 18:06 UTC (permalink / raw) To: Lennart Sorensen; +Cc: Jan Kiszka, Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 11:11 ` Jan Kiszka 2015-01-02 12:51 ` Gilles Chanteperdrix @ 2015-01-02 12:56 ` Gilles Chanteperdrix 2015-01-02 13:06 ` Jan Kiszka 2015-01-02 13:29 ` Philippe Gerum 2 siblings, 1 reply; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-02 12:56 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 12:56 ` Gilles Chanteperdrix @ 2015-01-02 13:06 ` Jan Kiszka 0 siblings, 0 replies; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 13:06 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 11:11 ` Jan Kiszka 2015-01-02 12:51 ` Gilles Chanteperdrix 2015-01-02 12:56 ` Gilles Chanteperdrix @ 2015-01-02 13:29 ` Philippe Gerum 2015-01-02 13:24 ` Jan Kiszka 2 siblings, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-02 13:29 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 13:29 ` Philippe Gerum @ 2015-01-02 13:24 ` Jan Kiszka 2015-01-02 14:02 ` Philippe Gerum 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 13:24 UTC (permalink / raw) To: Philippe Gerum; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 13:24 ` Jan Kiszka @ 2015-01-02 14:02 ` Philippe Gerum 2015-01-02 13:56 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-02 14:02 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 14:02 ` Philippe Gerum @ 2015-01-02 13:56 ` Jan Kiszka 2015-01-02 14:16 ` Gilles Chanteperdrix 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 13:56 UTC (permalink / raw) To: Philippe Gerum; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 13:56 ` Jan Kiszka @ 2015-01-02 14:16 ` Gilles Chanteperdrix 2015-01-02 15:06 ` Gilles Chanteperdrix 0 siblings, 1 reply; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-02 14:16 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 14:16 ` Gilles Chanteperdrix @ 2015-01-02 15:06 ` Gilles Chanteperdrix 2015-01-02 15:59 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-02 15:06 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 15:06 ` Gilles Chanteperdrix @ 2015-01-02 15:59 ` Jan Kiszka 2015-01-02 18:03 ` Gilles Chanteperdrix ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 15:59 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 15:59 ` Jan Kiszka @ 2015-01-02 18:03 ` Gilles Chanteperdrix 2015-01-02 18:07 ` Philippe Gerum 2015-01-03 19:40 ` [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point Gilles Chanteperdrix 2 siblings, 0 replies; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-02 18:03 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 15:59 ` Jan Kiszka 2015-01-02 18:03 ` Gilles Chanteperdrix @ 2015-01-02 18:07 ` Philippe Gerum 2015-01-02 18:09 ` Jan Kiszka 2015-01-03 19:40 ` [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point Gilles Chanteperdrix 2 siblings, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-02 18:07 UTC (permalink / raw) To: Jan Kiszka, Gilles Chanteperdrix; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 18:07 ` Philippe Gerum @ 2015-01-02 18:09 ` Jan Kiszka 2015-01-02 19:20 ` Philippe Gerum 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 18:09 UTC (permalink / raw) To: Philippe Gerum, Gilles Chanteperdrix; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 18:09 ` Jan Kiszka @ 2015-01-02 19:20 ` Philippe Gerum 2015-01-02 19:15 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-02 19:20 UTC (permalink / raw) To: Jan Kiszka, Gilles Chanteperdrix; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 19:20 ` Philippe Gerum @ 2015-01-02 19:15 ` Jan Kiszka 2015-01-02 19:31 ` Philippe Gerum 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 19:15 UTC (permalink / raw) To: Philippe Gerum, Gilles Chanteperdrix; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 19:15 ` Jan Kiszka @ 2015-01-02 19:31 ` Philippe Gerum 2015-01-02 19:28 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-02 19:31 UTC (permalink / raw) To: Jan Kiszka, Gilles Chanteperdrix; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 19:31 ` Philippe Gerum @ 2015-01-02 19:28 ` Jan Kiszka 2015-01-02 19:55 ` Philippe Gerum 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 19:28 UTC (permalink / raw) To: Philippe Gerum, Gilles Chanteperdrix; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 19:28 ` Jan Kiszka @ 2015-01-02 19:55 ` Philippe Gerum 2015-01-02 19:49 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-02 19:55 UTC (permalink / raw) To: Jan Kiszka, Gilles Chanteperdrix; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 19:55 ` Philippe Gerum @ 2015-01-02 19:49 ` Jan Kiszka 2015-01-02 20:18 ` Philippe Gerum 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 19:49 UTC (permalink / raw) To: Philippe Gerum, Gilles Chanteperdrix; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 19:49 ` Jan Kiszka @ 2015-01-02 20:18 ` Philippe Gerum 2015-01-02 22:05 ` [Xenomai] registry daemon mangement (was: Re: [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point) Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-02 20:18 UTC (permalink / raw) To: Jan Kiszka, Gilles Chanteperdrix; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* [Xenomai] registry daemon mangement (was: Re: [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point) 2015-01-02 20:18 ` Philippe Gerum @ 2015-01-02 22:05 ` Jan Kiszka 2015-01-02 22:17 ` Gilles Chanteperdrix 2015-01-03 18:36 ` [Xenomai] registry daemon mangement Philippe Gerum 0 siblings, 2 replies; 49+ messages in thread From: Jan Kiszka @ 2015-01-02 22:05 UTC (permalink / raw) To: Philippe Gerum, Gilles Chanteperdrix; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] registry daemon mangement (was: Re: [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point) 2015-01-02 22:05 ` [Xenomai] registry daemon mangement (was: Re: [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point) Jan Kiszka @ 2015-01-02 22:17 ` Gilles Chanteperdrix 2015-01-03 18:36 ` [Xenomai] registry daemon mangement Philippe Gerum 1 sibling, 0 replies; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-02 22:17 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] registry daemon mangement 2015-01-02 22:05 ` [Xenomai] registry daemon mangement (was: Re: [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point) Jan Kiszka 2015-01-02 22:17 ` Gilles Chanteperdrix @ 2015-01-03 18:36 ` Philippe Gerum 2015-01-03 20:09 ` Jan Kiszka 1 sibling, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-03 18:36 UTC (permalink / raw) To: Jan Kiszka, Gilles Chanteperdrix; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] registry daemon mangement 2015-01-03 18:36 ` [Xenomai] registry daemon mangement Philippe Gerum @ 2015-01-03 20:09 ` Jan Kiszka 2015-01-03 20:55 ` Philippe Gerum 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-03 20:09 UTC (permalink / raw) To: Philippe Gerum, Gilles Chanteperdrix; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] registry daemon mangement 2015-01-03 20:09 ` Jan Kiszka @ 2015-01-03 20:55 ` Philippe Gerum 2015-01-04 13:03 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-03 20:55 UTC (permalink / raw) To: Jan Kiszka, Gilles Chanteperdrix; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] registry daemon mangement 2015-01-03 20:55 ` Philippe Gerum @ 2015-01-04 13:03 ` Jan Kiszka 0 siblings, 0 replies; 49+ messages in thread From: Jan Kiszka @ 2015-01-04 13:03 UTC (permalink / raw) To: Philippe Gerum, Gilles Chanteperdrix; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-02 15:59 ` Jan Kiszka 2015-01-02 18:03 ` Gilles Chanteperdrix 2015-01-02 18:07 ` Philippe Gerum @ 2015-01-03 19:40 ` Gilles Chanteperdrix 2015-01-03 20:17 ` Jan Kiszka 2 siblings, 1 reply; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-03 19:40 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-03 19:40 ` [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point Gilles Chanteperdrix @ 2015-01-03 20:17 ` Jan Kiszka 2015-01-03 22:25 ` Gilles Chanteperdrix 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-03 20:17 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Xenomai 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-03 20:17 ` Jan Kiszka @ 2015-01-03 22:25 ` Gilles Chanteperdrix 2015-01-07 18:14 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-03 22:25 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-03 22:25 ` Gilles Chanteperdrix @ 2015-01-07 18:14 ` Jan Kiszka 2015-01-12 10:42 ` Gilles Chanteperdrix 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-07 18:14 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Xenomai 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-07 18:14 ` Jan Kiszka @ 2015-01-12 10:42 ` Gilles Chanteperdrix 2015-01-12 11:19 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-12 10:42 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-12 10:42 ` Gilles Chanteperdrix @ 2015-01-12 11:19 ` Jan Kiszka 2015-01-12 11:34 ` Gilles Chanteperdrix 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-12 11:19 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Xenomai 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-12 11:19 ` Jan Kiszka @ 2015-01-12 11:34 ` Gilles Chanteperdrix 2015-01-12 11:59 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Gilles Chanteperdrix @ 2015-01-12 11:34 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-12 11:34 ` Gilles Chanteperdrix @ 2015-01-12 11:59 ` Jan Kiszka 2015-01-12 14:35 ` Philippe Gerum 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-12 11:59 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Xenomai 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-12 11:59 ` Jan Kiszka @ 2015-01-12 14:35 ` Philippe Gerum 2015-01-12 14:34 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-12 14:35 UTC (permalink / raw) To: Jan Kiszka, Gilles Chanteperdrix; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-12 14:35 ` Philippe Gerum @ 2015-01-12 14:34 ` Jan Kiszka 2015-01-13 9:22 ` Philippe Gerum 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-12 14:34 UTC (permalink / raw) To: Philippe Gerum, Gilles Chanteperdrix; +Cc: Xenomai 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-12 14:34 ` Jan Kiszka @ 2015-01-13 9:22 ` Philippe Gerum 2015-01-13 9:11 ` Jan Kiszka 0 siblings, 1 reply; 49+ messages in thread From: Philippe Gerum @ 2015-01-13 9:22 UTC (permalink / raw) To: Jan Kiszka, Gilles Chanteperdrix; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-13 9:22 ` Philippe Gerum @ 2015-01-13 9:11 ` Jan Kiszka 2015-01-13 9:45 ` Philippe Gerum 0 siblings, 1 reply; 49+ messages in thread From: Jan Kiszka @ 2015-01-13 9:11 UTC (permalink / raw) To: Philippe Gerum, Gilles Chanteperdrix; +Cc: Xenomai 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point 2015-01-13 9:11 ` Jan Kiszka @ 2015-01-13 9:45 ` Philippe Gerum 0 siblings, 0 replies; 49+ messages in thread From: Philippe Gerum @ 2015-01-13 9:45 UTC (permalink / raw) To: Jan Kiszka, Gilles Chanteperdrix; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2015-01-13 9:45 UTC | newest] Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <mailman.787.1420134217.6101.xenomai-git@xenomai.org> 2015-01-02 10:28 ` [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point Jan Kiszka 2015-01-02 10:58 ` Philippe Gerum 2015-01-02 11:11 ` Jan Kiszka 2015-01-02 12:51 ` Gilles Chanteperdrix 2015-01-02 13:05 ` Jan Kiszka 2015-01-02 13:41 ` Gilles Chanteperdrix 2015-01-02 15:05 ` Lennart Sorensen 2015-01-02 15:10 ` Gilles Chanteperdrix 2015-01-02 15:22 ` Gilles Chanteperdrix 2015-01-02 15:47 ` Lennart Sorensen 2015-01-02 18:06 ` Gilles Chanteperdrix 2015-01-02 12:56 ` Gilles Chanteperdrix 2015-01-02 13:06 ` Jan Kiszka 2015-01-02 13:29 ` Philippe Gerum 2015-01-02 13:24 ` Jan Kiszka 2015-01-02 14:02 ` Philippe Gerum 2015-01-02 13:56 ` Jan Kiszka 2015-01-02 14:16 ` Gilles Chanteperdrix 2015-01-02 15:06 ` Gilles Chanteperdrix 2015-01-02 15:59 ` Jan Kiszka 2015-01-02 18:03 ` Gilles Chanteperdrix 2015-01-02 18:07 ` Philippe Gerum 2015-01-02 18:09 ` Jan Kiszka 2015-01-02 19:20 ` Philippe Gerum 2015-01-02 19:15 ` Jan Kiszka 2015-01-02 19:31 ` Philippe Gerum 2015-01-02 19:28 ` Jan Kiszka 2015-01-02 19:55 ` Philippe Gerum 2015-01-02 19:49 ` Jan Kiszka 2015-01-02 20:18 ` Philippe Gerum 2015-01-02 22:05 ` [Xenomai] registry daemon mangement (was: Re: [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point) Jan Kiszka 2015-01-02 22:17 ` Gilles Chanteperdrix 2015-01-03 18:36 ` [Xenomai] registry daemon mangement Philippe Gerum 2015-01-03 20:09 ` Jan Kiszka 2015-01-03 20:55 ` Philippe Gerum 2015-01-04 13:03 ` Jan Kiszka 2015-01-03 19:40 ` [Xenomai] [Xenomai-git] Philippe Gerum: copperplate: add configuration tunable for registry moint point Gilles Chanteperdrix 2015-01-03 20:17 ` Jan Kiszka 2015-01-03 22:25 ` Gilles Chanteperdrix 2015-01-07 18:14 ` Jan Kiszka 2015-01-12 10:42 ` Gilles Chanteperdrix 2015-01-12 11:19 ` Jan Kiszka 2015-01-12 11:34 ` Gilles Chanteperdrix 2015-01-12 11:59 ` Jan Kiszka 2015-01-12 14:35 ` Philippe Gerum 2015-01-12 14:34 ` Jan Kiszka 2015-01-13 9:22 ` Philippe Gerum 2015-01-13 9:11 ` Jan Kiszka 2015-01-13 9:45 ` Philippe Gerum
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.