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
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
