[PATCH 2/2] mount: -T OTHERTAB support

Isaac Dunham ibid.ag at gmail.com
Mon Mar 16 05:09:47 UTC 2015


Thanks for the clarifications; I've got some further comments below.

On Mon, Mar 16, 2015 at 03:19:45AM +0100, Harald Becker wrote:
> >First, request for clarification--does that mean:
> >mountpoint	owner:group	chmod	%fstype
> >
> >as it appears to?
> 
> yes, the percent sign triggers mount operation
> 
> Or better in addition (full intended syntax):
> 
> mountpoint owner:group mode %fstype [=device] [options]
> 
> --> mount -t fstype -o options device mountpoint
> 
> >/dev/mqueue, as mounted, is by default chmod 1777 (which seems rather lax
> >to me); the point of my example was that you can have different
> >permissions for the directory and the mount.
> 
> Aren't there any mount options for the filesystem type to set the default
> permissions? Ahh, looks like there left such things out :(

-o mode?

> Nevertheless, the intended extensions would allow to fix this to your
> wishes:
> 
> mqueue  root:root 0755 %mqueue
> mqueue/ root:root 1300
> 
> The second line is to create directories and setup there permissions,
> but they shall skip the creation, when the directory is already there.

I see (down below) that what I wanted is more like:
mqueue root:root 1300 %mqueue
mqueue/ root:root 1775


> dirname/  owner:group mode
> 
> The slash at the end of dir name triggers this type of rule, but mountpoint
> above may also end in a slash (for compatibility).
> 
> So you create the mount point with root:root, 0755, mount the mqueue mile
> system and afterwards you change the permissions of the mounted file system
> to 1300.
> 
> Isn't that more intuitive than digging through the shell scripts to find the
> place where things get setup to see / change the mode value for example?

Well, honestly, my first thought on a system I've never used would be
-grep through /etc/init.d/* for "mount" and then for "/dev"
-read whatever script that points at
-eventually, if I find /etc/mdev.conf, I'd be wondering what anything
there had to do with mounting filesystems, and would have to read an
explanation of that line two or three times.

But I suppose my mind has been warped by 9 years of sysvinit/openrc.
;-)

> 
> >- can you set the source name to something meaningful, rather than
> >having it always be "none" (yes, this is aesthetic) ?
> 
> yes :)  (default is "virtual" ... have I mentioned I hate that "none"?)
> 
> mqueue/ me:yours 0755 %mqueue =gugux und,das,sind,optionen
> mqueue/ root:nogroup 1300
<snip>
> >Apart from the mounts, sounds a lot like "makedevs".
> 
> Which started as lengthy list of mknod commands in a shell script, before I
> send the author my criticism voting for a more table driven version, but as
> his reaction was to slow, I stumbled away from this and never used it again.

I was thinking of the version in Busybox.
 
> >While I like the general concept of having only one authoritative source,
> >having that source be mdev.conf seems like you're asking for mdev to
> >become the One Tool to rule them all. ;)
> 
> Nope, the primary function of mdev.conf is device file system, where the
> proc and sys (including subsystems) are a maybe (preference).
> 
> Technically it would be possible to extend the usage to other stuff like
> /tmp, but this is not my intention.
> 
> As in shell scripts, it is up to the maintainer, which entries he places in
> mdev.conf. So the maintainer has full control, over who setup what and how.
> 
> 
> >I mean that feature creep seems to be the natural consequence, not
> >that your *goal* is to have mdev become "full system initialization in
> >one command".
> 
> You mean, what possible is, will be done? May be, but then you need to beg
> those who throw there crap into mdev.conf ... ok, I know: "Those who build
> guns, are not responsible for anybody killed." :(

> Ok, good argument, but can we do anything against this, except putting a
> clear description of this in docs/mdev.txt, saying those features are for
> setting up the device file system. Using /dev as the starting point for
> relative names, was one small step solving this argument.

What I mean is not that people might start using mdev for setting
up /sys as well as /dev, but that once that happens, people may start
thinking it's a good idea for mdev to do anything and everything
that involves filesystem manipulation, and each additional feature
makes it less and less clear that mdev is for converting hotplug
events to device nodes.

 
> >Might I suggest that you step back and ask yourself if there's a way to
> >mark this information to make it easy to split into the various
> >components, so that you can maintain more in one place without
> >requiring all your tools to expand in features?
> 
> I'm unsure what are you asking.
> 
> ... do you mean splitting of the mdev.conf files?
> 
> In the other thread I already suggested an include feature for mdev.con,
> e.g.
> 
> #include /etc/mdev-extra.conf
> 
> ... but also allow for including all files from a directory:
> 
> #include /etc/mdev.d/
> 
> ... but I expect, this was not your intention
> 
> ... so just clarify your question please.

Indeed, that's pretty much the reverse of what I meant.

Could the one "master file" you've referred to that controls everything
be the  *source* for mdev.conf, your fstab, and so on?


> >Also, I really am interested in what this looks like/lets you do
> >(in the sense of wanting to start experimenting some more.)
> 
> My usual steps of development are: Planning, hacking, testing on my
> machines, giving to those who like for more testing, solving complains, then
> pushing into mainstream. Does that solve your fears? Before I'm even trying
> to put that into the official BB version, you may grab a patch, build on
> your own and test it.

"this" meant "the single file controlling creation of everything".
Not what the proposed applet could do, but what the configuration
format you've mentioned that you already use looks like.

Thanks,
Isaac Dunham


More information about the busybox mailing list