RFD: Rework/extending functionality of mdev

[Harald Becker]

On 13.03.2015 00:05, Michael Conrad wrote:
> On 03/12/2015 04:32 PM, Harald Becker wrote:
>> On 12.03.2015 19:38, Michael Conrad wrote:
>>> On 3/12/2015 12:04 PM, Harald Becker wrote:
>>>> but that one will only work when you either use the kernel hotplug
>>>> helper mechanism, or the netlink approach. You drop out those who
>>>> can't / doesn't want to use either.
>>>
>>> ...which I really do think could be answered in one paragraph :-) If the
>>> netlink socket is the "right way" to solve the forkbomb problem that
>>> happens with hotplug helpers, then why would anyone want to solve it the
>>> wrong way?  I don't understand the need.
>
> To clarify,

Adding in here #0 - to not forget cold plug and semi automatic handling

>    1 - kernel-spawned hotplug helpers is the traditional way,
>    2 - netlink socket daemon is the "right way to solve the forkbomb
> problem"

ACK, but #2 blocks usage for those who like / need to stay at #1 / #0

>    3 - kernel-spawned fifo-writer, with fifo read by hotplug daemon is
> "solve it the wrong way".

NO!

This is splitting operation of a big process in different threads, using 
an interprocess communication method. Using a named pipe (fifo) is the 
proven Unix way for this ... and it allows #2 without blocking #1 or #0.


>> ohh, good question! ... ask Isaac! (answer in one paragraph?)
>
> What I hear Isaac say is "leave #1 (traditional way) alone.  I want to
> keep using it".
>
> I agree with him that it should stay.  But I would choose to use #2 if
> it were available.  I am asking the purpose of #3.

The purpose of #3 is splitting the hotplug handler needed for 
traditional #1 from the suffering part, putting this with some 
rearranging into a separate process and use a proven interprocess 
communication methode (IPC). Now you may use whichever mechanism you 
like, and whichever method you chose, it will benefit from overall speed 
improvement (as events tend to arrive in bursts, and there is no more 
extra parsing for the 2nd, and following events). That's it.

I try to provide the work to step to #3, allowing everybody to use the 
mechanism he likes, Isaac on the other hand block any innovation, 
forcing me and others to either stay at #1 too, or chose a different / 
external program (with consequence of code doubling or complex code 
sharing, the opposite to clarity).


> So I think your answer to my original question is "the fifo design is a
> way to have #1 and #2 without duplicating code".

The fifo design is a proven method to split operation of complex 
processes into smaller threads, using an interprocess communication method.

> In that case, I would offer this idea:

All you do, is throwing in complex code sharing and the need to chose a 
mechanism ahead at build time, to allow for switching to some newer 
stuff ... but what about pre-generated binary versions, which mechanism 
shall be used in the default options, which mechanism shall be offered?

With netlink active (sure the proven and better way for the job), you 
hit those like Isaac. With netlink disabled, spreading newer technology 
to the wide is usually blocked (don't talking about some experts who 
know how to build there own BB version).

So why not allowing some innovation, to let the user chose which 
mechanism to use? What is wrong with this intention?

I neither want to reinvent the wheel, nor go the udev way to create a 
big monolithic block, but I like to get the ability to setup the system 
the way I like, without blocking others to use the plug mechanism they like.

--
Harald