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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
