Hi Harald,
I'm sorry if I came across as dismissive or strongly opposed to the idea.
It was not my intent. My intent, as always, is to try and make sure that
potential new code 1. is worth writing at all, and 2. is designed the
right way. I don't object to discourage you, I object to generate discussion.
Which has been working so far. ;)
You missed the fact, I told everything stays under control of the
admin or system setup. Nobody shall be forced to do things in a
specific way. I want just give some extended functionality and
flexibility to do this setup in an very easy and IMO straight looking
way.
I understand your point. If I don't modify my mdev.conf, everything
will still work the same and I can script the functionality if I prefer;
but if you prefer centralizing the mounts and other stuff, it will also
be possible to do it in mdev.conf.
It is very reasonable. The only questions are:
- what are the costs of adding your functionality to mdev.conf ?
- are the benefits worth the costs ?
You may have noticed that I'm very conservative as far as code is
concerned ;) You're saying "I like centralized information, the
benefits are obvious to me" and I'm answering "I prefer scripting, so
I don't see the benefits to your change". It's a debate of taste, and
we'll never get anywhere like this. We need to dig a little more.
As a preamble, let me just say that if you manage to make your syntax
extensions a compile-time option and I can deactivate them to get the
same mdev binary as I have today, then I have no objection, apart from
the fact that I don't think it's good design - see below.
Sorry, I don't agree. mdev's purpose is to setup the device file
system infrastructure, or at least to help with setting up this. Ok,
at first leave out proc and sysfs, there you may be right, but what
about devpts on /dev/pts, or /dev/mqueue, etc., and finally the tmpfs
for /dev itself. Do you really say they do not belong to the device
file system infrastructure? Or all those symlinks like /dev/fd,
/dev/stdin, /dev/stdout, etc., do you consider them not to belong to
mdev? Not talking about setting owner informations and permissions
for those entries in the device file system.
OK, now this is interesting.
I firmly believe that most of our disagreement comes from the fact
that "mdev" and "mdev -s" are the same binary, but *not* the same
functionality at all.
To me, mdev.conf is a configuration file for "mdev" functionality,
i.e. configuration for a hotplug helper. Since mdev can be invoked on
every hotplug event, it's very important that mdev.conf parsing remain
fast.
You are saying that you would benefit from user interface improvements
to the /dev *initialization* functionality, i.e. "mdev -s". I understand,
and I agree that a one-stop-shop for /dev initialization would be nice.
My point, which I didn't make clear in my previous message because I was
too busy poking fun at you (my apologies, banter should never override
clarity), is that I find it bad design to bloat the parser for a hotplug
helper configuration file in order to add functionality for a /dev
initialization program, that has *nothing to do* with hotplug helper
configuration.
The confusion between the two comes from two places:
- the applet name, of course; I find it unfortunate that "mdev" and
"mdev -s" share the same name, and I'd rather have them called "mdev"
and "mdev-init", for instance.
- the fact that "mdev"'s activity as a hotplug helper is about creating
nodes, fixing permissions, and generally doing stuff around /dev, which
is, as you say, logically close to what you need to do at initialization
time, so at first sight the configuration file looks like a tempting
place to put that initialization time work.
But I maintain that mdev.conf should be for mdev, not for mdev -s.
mdev -s is just doing the equivalent of calling mdev for every device
that has been created since boot. If you make a special section in
mdev.conf for mdev -s, this 1. blurs the lines even more, which is not
desirable, and 2. bloats the parser for mdev with things it does not
need after the first mdev -s invocation.
Sure, all that can be done with some shell scripts, scattering around
all that information at different places, or the need to setup and
read/process different configuration files. My intention is to get
this information which depend on system setup in a single, relatively
simple to use or modifiable location.
I agree with that goal. I just don't think mdev.conf is the place to
do it.
The startup script itself just invokes mdev, which gets the information
from /etc/mdev.conf
No: the startup script invokes mdev -s, which invokes (or does the
equivalent of invoking) mdev, which gets the information from mdev.conf.
But the functionality you're planning to add is specific to mdev -s:
the actions would be taken by mdev -s but outside of its series of
mdev invocations.
And what else are a few lines, in mdev.conf, describing those mounts,
other then placing them in a separate "early mount points file"? ...
ok, lets go one step further on this. Let us add an "include" option
to mdev.conf, which allow to split the mdev configuration in
different files, and/or place mdev.conf lines in separate files in a
/etc/mdev.d/ directory. You like to have an "early mount points
file"? Put those mount informations in a file and add an include for
that file in mdev.conf ... ?
Well, my suggestion would be to keep mdev.conf as it is, and to
have an additional mdev-init.conf (or however you want to name it) file
with the syntax of your choice, specifically for the things you want
mdev -s to do that are not purely mdev invocations. One config file
for the hotplug helper, and a separate one for the one-time
initialization.
... and what is wrong about calling mount from mdev? Setting up the
device files system includes mount operations, so mdev should be able
to call mount, when and how it is required.
You're not going to call mount from mdev as a hotplug helper.
You're only going to call mount from mdev -s. Nothing wrong with that
if it's what you want, but I still believe you should keep the mount
stuff outside of mdev.conf.
My intention is to fork only one process, parse the conf
table once and then read sanitized events from stdin, scanning the in
memory conf table and invoking the right operations.
I went ahead and implemented the "netlink listener forking a
single process" thing, with the protocol I suggested in my previous
message:
http://skarnet.org/software/s6-linux-utils/s6-uevent-listener.html
(To get the s6-devd behaviour, I also implemented a s6-uevent-spawner
program, which reads from s6-uevent-listener and spawns a program for
every event. But that is the part you don't want. You want to write
a long-lived program that would be spawned by s6-uevent-listener.)
Feel free to try it, torture it, copy it and create your own stuff
based on it - this goes for Nathanaël too. I honestly don't think you
can get a much better netlink uevent listener than this,
resource-wise (it even uses posix_spawn() instead of fork(), for
noMMU systems) and simplicity-wise.
No, it is not unnecessary. The long lived instance tries to stay at
low memory usage, then forks and second instance read mdev.conf into
the memory table. When the event system goes idle, as it is most of
the time, the second instance dies and memory is freed to the
system.
I'm still not sold on that.
Even if the event system is idle most of the time, when an event
arrives, you *need* to handle it, and to handle it *now*. If you
don't have the resources when you need to spawn the second instance,
what do you do ?
- Drop the event ? That may be the most reasonable approach, but
it's not satisfactory: the event system isn't doing its job.
- Wait and retry ? If your system is hurting for memory so much that
it can't spawn a friggin' mdev, don't you think that queuing up the
events and delivering them 3 seconds later is going to make matters
worse instead of better ? Besides, with enough event queueing and
resource starvation, you may end up filling the kernel buffers and
dropping events anyway.
- Something else ?
If you're going to have a long-lived program at all, then I think
it's better to fully commit the resources you need to handle events
properly. I'm all for saving resources where they can be saved, but
really, guaranteeing you're not going to drop events (unless you
fill the kernel buffer, but meh...) at the cost of a sleeping busybox
process is a very good trade. I have hundreds of sleeping processes on
my resource-constrained systems, and they aren't complaining - because
every single one of my processes uses so little private memory that
it's hardly noticeable.
... and you just reinvented udevd. Congratulations ! ;)
Laurent this is not very friendly.
Sorry, you're right, it wasn't. Hey, with s6-uevent-listener,
I kinda reinvented udevd too! The easy part, at least.
Right, adding more to the conf language adds complexity there, but
removes complexity of the surrounding scripts and collect system
specific information at a central place (or places), usually hidden
deep in the startup scripts or some config files they use.
Again: I agree with you here, I just don't think mdev.conf is the
place to do initialization-but-not-hotplug operations.
IMO you are going off topic. Now you are talking about udev, and
modifying / using udev. We are most likely looking at systems using
mdev and are based on BB, not the upstream tools.
Well yes, it's off-topic for your practical initialization need here.
I can easily go on the udevd tangent, however, because I believe
that's the whole crux of the problem: no matter how well-designed
the hotplug helpers are, and no matter the mechanisms (hotplug or
netlink, short-lived or long-lived...), the difficult part of device
management is the actual userspace library, the list of actions
to take when such and such device gets plugged/removed/transmogrified.
This is absolute grunt work, which so far has been done for udevd,
and nothing else - not even mdev; and it's a shame, because it
perpetuates the reliance on the horrible mess that is udevd, and
marginalizes users of mdev or other solutions. If we wanted to
advertise a workable, credible alternative to udevd in the mainstream
world, we would need to come up with that huge device management
database. And this makes me recoil.
--
Laurent
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
