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

Harald Becker ralda at gmx.de
Mon Mar 16 16:24:02 UTC 2015


On 16.03.2015 06:09, Isaac Dunham wrote:
>> 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?

Don't have any experience with mqueue, (some) other virtual file systems 
have an option to set the mode.


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

Which ever you like, and makes sense. It is your config file and up to 
you, what you put in there. I did never intend any restrictions to the 
used options, just some simple format checking, then forwarding to the 
appropriate calls.


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

Sure, it is a different approach then the usual shell script style, but 
most of those I met and had a deeper look at the principle, felt it is 
of very practical use.

... but even if the feature is included in BB, nobody is encouraged to 
use them. Old script style setup of things is still there and possible.


> I was thinking of the version in Busybox.

Ohps, didn't look at this one, as I had already my table driven dev 
setup, when those commands arrived ... but then dev file system came 
into existence and the hot plug stuff.


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

This mets somehow the fears and wishes of Laurent, to split the initial 
commands / setup from the device definitions, which could be wise.

Both configs then just share the same syntax, but this is pure 
preference, if you like the way to collect information at a central 
place, or vote for more separation into logical groups.

My intention of the mdev.conf extensions are highly for usage on device 
file system and (with some fuzziness) the virtual file systems proc and 
sys. May be someone include putting a tmpfs on /var/run or /run or 
something similar, but this already highly depend on preference.

Technically, there is no specific limit on what you setup with this 
feature, as is with providing the commands in a shell script. It's up to 
you, what you do with the available tools.


>> In the other thread I already suggested an include feature for mdev.con,
>> e.g.
>
> 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?

Do I understand you right, if I assume you're asking if it would be 
possible to put also the functions of fstab, and may be some other 
system setup related information in a single, table driven file?

If you like, sure, most of them, with some slight extended syntax. The 
details have be looked for, but I do not see any principal problem for 
this. I'm open to suggestions on this -> and that won't have an impact 
on the hotplug / netlink question or other operation of the device settings.

Even for other commands and functions, the table driven approach can be 
used, without need to change there operation, as you are able to create 
the appropriate config files for the other functions from the initial 
table driven setup. On a read only root file system you may just set 
symlinks in /etc for those config files to a tmpfs on e.g. /var or /run, 
and then create / modify the config files there. On a few systems I did 
already similar with some shell / sed / awk scripting.

Let me think a bit about that: Could be wise to split things into two 
functional groups, doing all the initial stuff and the device 
descriptions? What do you think?

So we won't have an "xdev -i" and other xdev functions, but a separate 
applet (call it sysstart CONF_FILE, for now) to run the table driven 
system startup and the xdev / mdev for the device file system operations 
... sounds not so bad for me!

Does that fit better your question?


Just to note: If we do that table driven approach with an own applet 
that can be thought of a kind of script interpreter:

put this as your first line in /etc/my-sysstart:

#!/bin/busybox sysstart

than you could just do:

/etc/my-sysstart [ARGS]



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

The proposed format is just like the possible commands you may put into 
a script, there is no special invented limitation. The information is 
read from the conf file, sanity checked to fit some principal format 
guidelines, and then forwarded to a big case, which does call the 
appropriate system commands, just like any shell script does.

So if you ask, to what this may be extended? To much, without immense 
cost, and no impact on other setup, except mixing incompatible system 
designs (e.g. mixing usage of /var/run and /run). It is just the 
question if it's liked, which functionalities are requested, and some 
brain work to design the syntax for the setup table format.

The table driven approach is in it's theory not different than that of 
other shell scripting, except you set the focus more on what is setup, 
and not looking at / giving the glory details on how it's done (the 
exact details of commands called to achieve a specific function).

... and is not limited to system setup purposes. You may use it for any 
matching purpose, and e.g. control setting up a chroot environment on 
the fly.

--
Harald


More information about the busybox mailing list