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.

_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to