RFD: Rework/extending functionality of mdev

[Harald Becker]

On 13.03.2015 12:29, Michael Conrad wrote:
> On 3/13/2015 3:25 AM, Harald Becker wrote:
>>>    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
>>
>>> 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?
>
> Please review it again.  My solution solves both #1 and #2 in the same
> binary, with no code duplication.

At first complex code reusage, and then: How will you do it without 
suffering from hotplug handler problem as current mdev? I'm don't 
seeing, that you try to handle this problem. My solution is to enable 
kernel hotplug handler mechanism to also benefit and avoid that parallel 
parsing for each event.

... beside that, this close / open_netlink look suspicious, looks like 
possible race condition.

What es wrong with splitting a complex job into different threads? The 
splitting alone, with inserting the named pipe (a long proven IPC), is 
enough to let even kernel hotplug mechanism based system, to gain speed 
improvement (and expected less memory usage on system startup). On 
modern multi core machines this will also allow the split operations to 
run on different CPU cores, with no extra cost. Synchronized operation. 
Where your Solution still hold the possibility of race conditions from 
possible parallelism.


> I suggested wrapping #2 in a ifdef for the people who don't have netlink
> at all, such as on BSD, and also anyone who doesn't want the extra bytes.

Therefor is my approach to allow for opt out in the config, but brings 
me otherwise to the idea to throw a compiler error, when netlink is 
build on system where not available, or optionally a warning and auto 
disable netlink support (usually a 4 liner snipped at the code start).

#if CONFIG_FEATURE_MDEV_NETLINK && NETLINK_NOT_AVAILABLE
   #define CONFIG_FEATURE_MDEV_NETLINK 0
   #warn "This system lacks netlink support, netlink disabled"
#endif

... or something similar.

--
Harald