[RFC] Proof-of-concept for netlink listener for mdev -i

[Harald Becker]

On 15.03.2015 14:29, Natanael Copa wrote:
>> You hacked a solution, for the mechanism of your preference, throwing
>> out those who want to use one of the other mechanisms ...
>> this is forcing others to do it your way?
>
> The RFC in subject means "request for comments", not "I force you do it
> my way".

I apologize ... please change my words to (which was there intention):

You hacked a solution, for the mechanism of your preference, throwing 
out those who want to use one of the other mechanisms ... which would be 
bad, when you try to force others to do it your way?

... sorry for my poor English.


>> ... and what is the major difference of your hacked code and my intended
>> solution?
>
> My way does not use anonymous pipe instead of named pipe? (no mkfifo
> call)

What are the difference between private pipes and named pipes, except 
the possibility to let other processes get access to the pipe 
descriptor? Which is a requirement, when you want to open up and allow 
for different front ends with the same back end, using an IPC.


> The example was to show *one* way to solve a problem I am interested
> in. ...

That's it, to "solve one way, you are interested in", but your way will 
block other wishes and usages, without duplicating code, or the need of 
complex code sharing.

> (I'm still not sure we try solve same problem)

I'm trying to create a tool, with not much overhead compared to current 
mdev, which allow the system maintainer to setup the system withth the 
plug mechanism he likes, but let all benefit from resource and speed 
optimization on event bursts.

Therefore: I *know* we are not trying to solve the same problem!


> I am not trying to stop you do it vise versa.
> Are you trying to force me to discuss ideas your way?

Sorry, if my response took the wrong words, but you could have chosen 
different words for some expressed things, too ... or may be, I just 
misunderstood them ...


> I think you have a point here though. It should be possible to solve it
> without pipes/fifos at all.

By what? By putting all together in one monolithic block, e.g:

   read conf file into memory
   establish netlink socket
   wait for event
     gather information
     search for matching line in table
     do device operation

Is this your intention? Then you come into trouble when you try to let 
the kernel hotplug helper mechanism benefit from improvements. 
Especially re-parsing the conf file for every event.


> It should be possible to solve the hotplug problem by setting up
> netlink listener, wait for event, when event arrives fork helper and
> just hand over the netlink socket filedescriptor to the child. That way
> we avoid pipes/fifos alltogehter. And we avoid the splitted messages
> problem too.

Which would mean to move over the netlink reader to the parser process, 
making it even more complex to use the same parser back end for 
different purposes.

> That would also make it possible to replace the netlink socket with a
> named pipe for those who wants that.

? Don't know what you are intending here, and how you want to achieve that.


> In theory, the netlink socket (or named pipe) could be set up of a
> separate process. That way we avoid the init code in memory of longtime
> running process. Not sure its worth it thoug.

You mean splitting the netlink creator, from the netlink waiter, from 
the netlink reader ... even if I see, it could be possible, for which 
result? Complexity! ... I'm trying to go the opposite way, clarity and 
modularity. Not only a solution for one group of people.

--
Harald