RFD: Rework/extending functionality of mdev

[Michael Conrad]

On 3/13/2015 11:21 AM, Harald Becker wrote:
> On 13.03.2015 12:41, Michael Conrad wrote:
>> Stream-writes are not atomic, and your message can theoretically get
>> cut in half and interleaved with another process writing the same
>> fifo.  (in practice, this is unlikely, but still an invalid design)
>
> ---snip---
> O_NONBLOCK disabled, n <= PIPE_BUF
> All n bytes are written atomically; write(2) may block if there is not
> room for n bytes to be written immediately
> ---snip---
>

I stand corrected.  I thought there would be a partial write if the pipe 
was mostly full, but indeed, it blocks.


>> If someone really wants a netlink solution they will not be happy
>> with a fifo approximation of one.
>
> You missed the fact, my approach allows for free selection of the 
> mechanism. C hosing netlink means using netlink, as it should be. The 
> event listener part is as small as possible and write to the pipe, 
> which fire up a parser / handler to consume the event messages.

Are you suggesting even the netlink mode will have a process reading the 
netlink socket and writing the fifo, so another process and can process 
the fifo?  The netlink messages are already a simple protocol, just use 
it as-is.  Pass the


On 3/13/2015 12:14 PM, Harald Becker wrote:
>> The new code would not be run like a hotplug helper, it would be run as
>> a daemon, probably from a supervisor.  But the old code is still there
>> and can still be run as a hotplug helper.
>
> The new code behaves exactly as the old code. When used as a hotplug 
> helper, it suffers from parsing conf for each event. My approach is a 
> splitting of the old mdev into two active threads, which avoid those 
> problems even for those who like to stay at kernel hotplug.

Then it sounds like indeed, you are introducing new configuration steps 
for the old-style hotplug helper?  i.e. where does the fifo live?  who 
owns it? what security implications does this have?  Who starts the 
single back-end mdev processor?  If started from the hotplug-helper, who 
ensures that only one gets started?

If people have existing systems using hotplug-helper mdev, you can't 
just change the implementation on them in a way that requires extra 
configuration.  Everyone who has commented on this thread so far agrees 
with that.

-Mike