Hi Isaac !
> Agreed, whole-heartedly.
I just don't think you're quite thinking through exactly what this means.
In which sense? Let me know, what I got wrong. I'm a human, making
mistakes, not a perfect machine.
Agreed.
But I would include "hotplug daemons" under "etc."
I used "etc." so add any similar type of program you like, including
"hotplug daemons" ... but stop, what are "hotplug daemons"? Do you mean
daemons like udev? udev uses netlink reading. Otherwise I know about
hotplug helper programs (current mdev operation), but not about "hotplug
daemons".
The gathering parts need to acquire the device information, sanitize this
information, and serialize the event operations to the right order. The
device node handling part shall receive the information from the gathering
part(s) (whichever is used) and call the required operations, but shall
avoid reparsing the conf on every event (speed up) *and* drop as much memory
usage as possible, when the event system is idle.
That *shall* is where you're forgetting about the first principle you
mentioned (assuming that you mean "shall" in the normative sense used
in RFCs).
??? Sorry, may be it's I'm not a native English speaker. Can you explain
me what is wrong? How should it be?
Yes, some people find the hotplugger too slow.
But that doesn't mean that everyone wants a new architecture.
What do you mean with new architecture? Different system setup? Changing
configuration files?
My first approach was not to change usage of current systems. Except a
slightly bigger BB, you should not have noted from my modifications.
Then came Laurent with some questions and suggestions to split of some
things for clarification, so the changes may result in slightly modified
applet names and/or parameter usage (still under discussion), to be able
to adopted all functionality ... but otherwise you won't need to change
your setup, if you do not like.
Some people, at some points in time, would prefer to use a plain, simple,
hotplugger, regardless of whether it's slow.
??? Didn't you notice the following:
> - using the hotplug handler approach of the kernel
> (current operation of "mdev")
(Personally, I'd like a faster boot, but after that a hotplugger that
doesn't daemonize is fine by me.)
Do you really like forking a separate conf parser for each hotplug
event, even if they tend to arrive in bursts?
Won't you like to get a faster system startup with mdev, without
changing system setup / configuration?
So, in order to respect that preference, it would be nice if you could
let the hotplug part of mdev keep doing what it does.
What expect you to be the hotplug part? The full hotplug handler
including conf file parser, spawned in parallel for each event?
Won't you like to benefit from a faster system startup, only why you
fear there is another (minimalistic) daemon sitting in the back? Sounds
like "automobiles are dangerous, I won't use them"? ... sorry if this
sounds bad, I try to understand what exactly you are fearing ... I
expect you did misunderstand something (or I explained / translated it
wrong).
My idea is a fifo approach. This allows splitting the device management
functionalities. Nevertheless which approach to gather the device
information is used, the parser and device handling part can be shared (even
on a mixed usage scenario).
I understand that the goal here is to allow people to use netlink or hotplug
interchangeably with "mdev -p" (which I still think is a poorly named
but very desireable feature).
Please don't stay at those specific parameter names, think of specific
functionalities. The names are details under discussion ... but here
especially I expect you misunderstand something. "mdev -p" would be for
internal purpose to distinguish invocation from the usual "mdev", and
"mdev -s" usage (current mdev). So if you won't change your system setup
to benefit from extra functionality, you won't ever need "mdev -p", it
is for internal usage and special purposes (the p stands for parser, a
quick and dirty selection, to use something).
As stated before, I don't think that this approach is really functional,
and would be more opposed to using it than to using netlink or a plain
hotplugger. For this reason, I'm opposed to including it in *mdev*.
??? Not functional? In which way? What does you fear?
I also think that those who *do* want to use this approach would benefit
more from a non-busybox binary, since the hotpluggger needs to be as
small and minimal as possible. Hence, I suggest doing it outside busybox.
Yes, that hotplug helper may benefit from being as small and fast as
possible, but a separate program means a separate binary, and that
conflict with my one single statical binary preference, which I share
with others. I consider splitting of that helper in a separate binary is
under discussion, but otherwise won't change anything on the concept (it
is not much more than a compile / link question).
But *if* you prefer to have it in busybox, I'd suggest doing a new applet
named (for example) "afifohp" (A FIFO HotPlugger, so named because it
would be one of the first entries in the multiplexer and that's what
it does).
Ugly name :( ... but otherwise please don't stick on specific names,
they where examples and are under discussion. My concern is the
functionality. Changing names and parameter letters is hacking code.
This would become the FIFO-reading daemon if need be, and dump its
environment into the fifo or (as daemon) read from the fifo, spawn
mdev -p, and write to a pipe.
I'd assume it needs a *simple* config file, which could be just a line
or two:
/sbin/mdev -p
timeout <n>
??? <confused> :(
I understand this architecture.
I'm saying that
* Since I think that the hotplug-compatible shim is worse than a plain
hotplugger, I would much prefer it if you left us a plain hotplugger
What is a plain hotplugger for you? Running many parser in parallel?
The intention is to allow any type of usage, this includes the kernel
hotplug feature, but with the benefit of faster event handling on bursts.
I think you do not understand the operation of the minimalistic fifo
daemon. It's main purpose is to avoid this parallelism, and beside that
add some failure handling possibility (when parser fails, if you like).
The fifo daemon will never read any data from the fifo, nor write
anything. It just holds the fifo open and available (e.g. for the
hotplug helper) and then waits until any data arrives in the fifo, then
it starts up the parser / handler process and wait until that process
exits. The exit status can than be checked and on failure a user defined
script may be started, else just goes back to the beginning waiting for
more data arriving in fifo, starting a new parser process.
This is simple N to 1 on demand Unix style inter process communication.
* If you do want to use this architecture, keeping this shim as minimal
as possible is extremely desireable; this implies that it should not be in
mdev, and probably not in busybox.
Don't you expect, forking several mdev conf parser in parallel event
burst eat up your system memory en massive?
May be, if you look at a single event, the memory consumption is a bit
higher than current mdev usage, but even with a bigger BB binary size,
is the expected memory usage on the hotplug handler type of operation
not much more than two in parallel running parser processes. At least on
the third or fort event in the burst, your memory consumption will be
less than current requirements ... and starting at the second event in
the burst you gain from system speed improvements, after some slight
delay on first event, when a new parser process needs to start. So
again, at least at the third or forth event in the burst you shall be
faster.
On current mdev operation the memory consumption increases linear with
the number of parallel arriving events (burst). Does my approach need
more as a single mdev invocation? Yes, somewhat more. Does it need more
memory than two parallel running mdev parser? I don't can tell you the
glory details ahead, so I simply expect equal cost. Does it need more
memory than three parallel running mdev parser? No, should not happen,
as only one parser process stays active for a while.
I've used init=/bin/sh many times.
If I forget the correct commands, I usually go
cat /etc/init.d/<hotplug handler>
or something similar; this is sometimes but not always on the same computer.
The init feature is an optional feature, use it if you like it, else
leave it. I don't expect much size improvement for that added
functionality, even if not opted out.
But there are difficulties that adding "mdev -i" causes:
-If someone refers to a computer where it's configured to set up one where
it isn't, this can cause major confusion.
This is true for any swap from one distro / system to another, therefore
I don't see an argument here.
-Someone could use it in their initscripts, but end up getting an
incompatible mdev.conf (for example, if a packager switches it on
without guaranteeing that the new entries find their way into mdev.conf,
it will likely cause widespread failure to boot.)
Incomplete or invalid configuration likely produce system failures, so
where is the argument? ... any init command can still be done by
scripting, or by hand, but your system will also fail if you smashed
your init scripts somehow. So ?
-It means that I have to refer to two files, and decode mdev.conf
into shell.
??? <confused>
Adding "mdev -h" is likely to cause more confusion, since "-h" is commonly
used to find help.
Ok, please dont stick on a specific parameter name, that -h is a
preference question, i like to have -? for the help, as many other
coming from the old Unix world ... es far as I know -h is a GNU-ishm.
A line in the help text mentioning
echo /sbin/mdev >/proc/sys/kernel/hotplug
would be at least as helpful.
Setting the hotplug helper name with an option is an extended feature to
simplify one command device system startup ... a feature you may use
when you like, else you can do it the old way. So what is wrong? Do you
want to block the ability to have some improved functionality? Why do
you think this is better?
Ahhh, you hit me ... this functionality does include a second operation,
it checks availability of the fifo and starts the fifo daemon if
required, that is what I mentioned as slight change, you need to add one
extra parameter or command (depending on how it's implemented). Either
you need to start the fifo daemon (by hand), or let it do an extra
option / command (comfort). The benefit from this is the modularity
(type of operation), and avoidance of parallel parser starts /
rescanning conf on each event (speed improvements).
This could be avoided if only one type of operation is used in an
implementation, either kernel hotplug helper or netlink uevent reader.
Allowing to have both functionalities included and let the user decide
which one he want to use, requires that extra fifo startup (else
unnecessary cost on hotplug events). ... but gives the additional
benefit of talking to the device file system management in a
synchronized fashion from user space commands.
The following questions to this topic:
- are MODALIAS requests send to same netlink socket as device events?
I would assume so, since they're part of the uevents.
I haven't checked, though.
I expected this, but didn't find the time to check it.
- does the module handling need and / or benefit from synchronization with
the device node handling, or is choosing parallelism the better approach?
Generally, you will either load a module or make a device node.
It's *possible* that you'll need to do both in some odd case.
The question is, does it need it's own fifo / pipe or may it use the
existing fifo infrastructure? ... but it wouldn't make much difference
to setup another fifo for modalias requests. The major change will be
the change of modprobe to let it read the requests from stdin / pipe /
fifo. The rest are minor changes, and letting netlink daemon distinguish
modalias requests from uevents, sending to the right fifo.
--
Harald
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
