RFD: Rework/extending functionality of mdev

[Harald Becker]

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