RFD: Possible idea to help on solving kernel hotplug reorder problem

[Harald Becker]

Part of the information hopped to a different thread, so it is possibly 
better to split this question of to a separate thread:

For those who want to use the kernel hotplug helper mechanism, the 
netlink interested are not affected by this.


The Problem:

The kernel spawns a separate process for each event, who gathers the 
information for this event. The startup of those processes go into 
parallel, when events arrive in bursts. This has the race condition, of 
reordering the device node operations. Avoid such reordering, mdev uses 
a special file to check a sequence number.

More description in doc/mdev.txt


Idea:

Splitting the gathering parts from the parser / handler, may allow to do 
this checking in a slight different way, which would avoid massive 
writing / reading a file.

When the hotplug helper (or netlink reader) gathers the event 
information, the sequence number of this event can be send ahead of the 
message to the parser. The parser may check this sequence number as 
explained, but push the message in a backlist, when sequence is wrong.

Then parser continue with message reading, checking merging incoming 
messages with the backlist, until it get a message of right sequence 
number or some timeout, which will hop to the nearest sequence number in 
the backlist.

When doing that carefully, we will be able to avoid actively waiting for 
the message getting into the right sequence.

Before the parser exits, it has to write the sequence number in the file 
and read it back (once) on next startup. No more polling until matching 
sequence number.

I did not dig deeper into this, but I wont lose that idea, so I put this 
into it's own thread for separate discussion.

Current state is pure idea, we could do this, but we can also stay at 
current mdev sequence ordering solution. I did not dig into the details 
yet, but will do that when it's the time for this.