On Fri, Nov 28, 2014 at 01:07:31PM +0100, Jan Kiszka wrote:
> On 2014-11-28 12:55, Gilles Chanteperdrix wrote:
> > On Fri, Nov 28, 2014 at 12:50:39PM +0100, Jan Kiszka wrote:
> >> On 2014-11-28 10:57, Gilles Chanteperdrix wrote:
> >>> On Fri, Nov 28, 2014 at 10:55:56AM +0100, Jan Kiszka wrote:
> >>>> On 2014-11-28 10:50, Gilles Chanteperdrix wrote:
> >>>>> On Fri, Nov 28, 2014 at 10:40:27AM +0100, Jan Kiszka wrote:
> >>>>>> On 2014-11-28 00:15, Gilles Chanteperdrix wrote:
> >>>>>>> On Thu, Nov 27, 2014 at 09:43:34PM +0100, Jan Kiszka wrote:
> >>>>>>>> On 2014-11-27 21:34, Gilles Chanteperdrix wrote:
> >>>>>>>>> On Thu, Nov 27, 2014 at 02:14:38PM -0500, Lennart Sorensen wrote:
> >>>>>>>>>> On Thu, Nov 27, 2014 at 07:51:27PM +0100, Jan Kiszka wrote:
> >>>>>>>>>>> On 2014-11-27 19:18, Gilles Chanteperdrix wrote:
> >>>>>>>>>>>> According to the filesystem hierarchy standard, /mnt is the 
> >>>>>>>>>>>> standard
> >>>>>>>>>>>> place for "temporarily mounted filesystems".
> >>>>>>>>>>>>
> >>>>>>>>>>>> http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> >>>>>>>>>>>
> >>>>>>>>>>> Right, another reason to NOT mess around with it: if something was
> >>>>>>>>>>> temporarily mounted there, we will create the mountpoint inside 
> >>>>>>>>>>> that
> >>>>>>>>>>> filesystem with unforeseeable side effects.
> >>>>>>>>>>
> >>>>>>>>>> I always read that as "temporarily mounted there by the admin or 
> >>>>>>>>>> some
> >>>>>>>>>> other human".  Certainly not automatic mounts by software.  There 
> >>>>>>>>>> is a
> >>>>>>>>>> reason /media and such exists on many distributins.
> >>>>>>>>>
> >>>>>>>>> I would not venture an "always", autofs for instance, used to mount
> >>>>>>>>> things under /mnt. and /media has not always existed either, we used
> >>>>>>>>> /mnt/cdrom.
> >>>>>>>>
> >>>>>>>> FHS on /mnt purpose:
> >>>>>>>>
> >>>>>>>> "This directory is provided so that the system administrator may
> >>>>>>>> temporarily mount a filesystem as needed. The content of this 
> >>>>>>>> directory
> >>>>>>>> is a local issue and should not affect the manner in which any 
> >>>>>>>> program
> >>>>>>>> is run."
> >>>>>>>>
> >>>>>>>> I think this makes it crystal clear that Xenomai is not supposed to
> >>>>>>>> touch it.
> >>>>>>>
> >>>>>>> Just to add another argument. I just asked a friend who is a
> >>>>>>> professional sysadmin. He creates directory under /mnt and mount
> >>>>>>> things under these directories. So, I am not sure the standard is
> >>>>>>> even applied by the people who should use it.
> >>>>>>>
> >>>>>>> If you read on the last site I sent, under the /media article: 
> >>>>>>>
> >>>>>>> Amid much controversy and consternation on the part of system and
> >>>>>>> network administrators a directory containing mount points for
> >>>>>>> removable media has now been created. Funnily enough, it has been
> >>>>>>> named /media.
> >>>>>>>
> >>>>>>> Are you sure, 100% sure, that every Xenomai user expects to be able
> >>>>>>> to use /mnt as a mount point? Or that they will create directories
> >>>>>>> under /mnt like everybody has been doing since Linux exists?
> >>>>>>
> >>>>>> I'm both absolutely sure that a) has to be left alone by Xenomai 
> >>>>>> because
> >>>>>> of requirements of the FHS and the way /mnt is used and b) we should 
> >>>>>> try
> >>>>>> hard to avoid creating temporary dirs in persistent filesystems.
> >>>>>
> >>>>> This is ridiculous. Because the standard changed, and one
> >>>>> distribution, Debian, decided to follow the new standard, which
> >>>>> seems to be not widely accepted, and even controversial, you want to
> >>>>> impose what Debian does to everybody. The distribution I use has
> >>>>> mount points under /mnt. So, why following Debian and not the
> >>>>> distribution I use, and what sysadmin have been doing for ages?
> >>>>>
> >>>>> You want the mount point to be somewhere else? Fine, put a symbolic
> >>>>> link.
> >>>>>
> >>>>> mkdir /run/xenomai
> >>>>> ln -s /run/xenomai /mnt/xenomai
> >>>>
> >>>> Again, this is not acceptible as /mnt changes all the time and exposes
> >>>> various remote filesystems which will hide that link.
> >>>
> >>> You are missing the point. Yes, Debian does that, but not all
> >>> distribution. Other distributions do not do that.
> >>>
> >>
> >> SUSE, Ubuntu, Gentoo, Red Hat - it's already standard. But I will change
> >> my patch to /var/run to avoid surprises with other/older distros.
> > 
> > Again, using /mnt/xenomai does not break any distribution following
> > the standard.
> > 
> > Let us try things another way, the possibilities we have are:
> > - /mnt/xenomai: a solution that used to be standard but ceased to be
> > with the FHS which did not provide a standard replacement, but does
> > not break any distribution
> 
> I don't remember that this was ever a standard. My distro (SUSE) never
> used it like this as long as I can remember (~18 year).
> 
> > - /run/xenomai: a solution that relies on the existence on the /run
> > directory, which is not standard, but is going to be, maybe.
> > - /var/run/xenomai: a solution which does not violate any version of
> > the standard, but is not standard either, does not make clear that
> > the directory is a mount point (which /mnt does), breaks the
> 
> This is how it's used in practice:
> 
> gvfsd-fuse on /var/run/user/1000/gvfs type fuse.gvfsd-fuse
> (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)

I note that you carefully avoid quoting and answering the part of my
answer that pointed to the issues raised by your patch.

-- 
                                            Gilles.

_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai

Reply via email to