On 13.03.2015 14:20, Didier Kryn wrote:
There are interesting technical points in this discussion, but it
turns out to be mostly about philosophy and frustration.
ACK :(
Hotplug is KISS, it is stupid, maybe, but it is so simple that you
can probably do the job with a script. The same serialization you
propose to implement in user space by the mean of several processes, a
named pipe and still the fork bomb, has been implemented in the kernel
without the fork bomb: it is called netlink.
You mixed some things, may be due to my poor English:
- current mdev suffers due to parallel reparsing conf for every event
- for those who like to stay at kernel hotplug mechanism, my approach
gives some benefits, but will not solve every corner case; but it looks
like, I could extend the approach somewhat, to do easier serialization
(this needs some more checking).
- for those who want to use netlink, it is a small long lived netlink
reader, pushing the event messages forward to the central back end (who
frees resources when idle). That shall work as a netlink solution should
So where is your concern? Using a pipe for communication from to another
process? This is Unix IPC / multi threading. Nothing else.
These people you are talking of, who would like to see hotplug
serialized but do not want netlink, do they really exist? This set of
people is most likely the empty set. In case these really exist, then
they must be idiots, and then, well, should Busybox support idiocy?
As soon as you can proof, set set of users is empty or hold only a
dropable minority, we can set default config for the kernel hotplug
mechanism to off, so it will be excluded from pre-build binaries. When
nobody more complains. That's it, you get a netlink solution.
I agree it's fun to have all tools in one static binary. But I dont
see any serious reason to make it an absolute condition. You speak of
*preference*, but this very one looks pretty futile. I don't see the
problem with having even a dozen applications, all static, why not, I'm
also a fan of static linking.
I explained it already in the other thread to Laurent. It is my way. I
try to avoid forcing others to do things in a specic way, but I hat to
be forced by others. Busybox is a public tool set and shall provide the
tools, which allow the user / admin to setup the system as he like. My
approach is to let others use kernel hotplug mechanism, if they lik, but
still gain performance boost, and users who like to use netlink, get a
netlink solution. The cost is some unused bytes in the pre-build
binaries (may be opted out in build config).
So where do I fail? Neither the optional event gathering parts (which
will try to stay as fast / small as possible), nor the parser / device
operation handler does work different than before (except some code
reordering to avoid parsing conf file for each event). The job mdev does
has just got split up in different threads, using a proven interprocess
communication technique (IPC). Again, where do I fail?
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
