On 13.03.2015 00:05, Michael Conrad wrote:
On 03/12/2015 04:32 PM, Harald Becker wrote:
On 12.03.2015 19:38, Michael Conrad wrote:
On 3/12/2015 12:04 PM, Harald Becker wrote:
but that one will only work when you either use the kernel hotplug
helper mechanism, or the netlink approach. You drop out those who
can't / doesn't want to use either.
...which I really do think could be answered in one paragraph :-) If the
netlink socket is the "right way" to solve the forkbomb problem that
happens with hotplug helpers, then why would anyone want to solve it the
wrong way? I don't understand the need.
To clarify,
Adding in here #0 - to not forget cold plug and semi automatic handling
1 - kernel-spawned hotplug helpers is the traditional way,
2 - netlink socket daemon is the "right way to solve the forkbomb
problem"
ACK, but #2 blocks usage for those who like / need to stay at #1 / #0
3 - kernel-spawned fifo-writer, with fifo read by hotplug daemon is
"solve it the wrong way".
NO!
This is splitting operation of a big process in different threads, using
an interprocess communication method. Using a named pipe (fifo) is the
proven Unix way for this ... and it allows #2 without blocking #1 or #0.
ohh, good question! ... ask Isaac! (answer in one paragraph?)
What I hear Isaac say is "leave #1 (traditional way) alone. I want to
keep using it".
I agree with him that it should stay. But I would choose to use #2 if
it were available. I am asking the purpose of #3.
The purpose of #3 is splitting the hotplug handler needed for
traditional #1 from the suffering part, putting this with some
rearranging into a separate process and use a proven interprocess
communication methode (IPC). Now you may use whichever mechanism you
like, and whichever method you chose, it will benefit from overall speed
improvement (as events tend to arrive in bursts, and there is no more
extra parsing for the 2nd, and following events). That's it.
I try to provide the work to step to #3, allowing everybody to use the
mechanism he likes, Isaac on the other hand block any innovation,
forcing me and others to either stay at #1 too, or chose a different /
external program (with consequence of code doubling or complex code
sharing, the opposite to clarity).
So I think your answer to my original question is "the fifo design is a
way to have #1 and #2 without duplicating code".
The fifo design is a proven method to split operation of complex
processes into smaller threads, using an interprocess communication method.
In that case, I would offer this idea:
All you do, is throwing in complex code sharing and the need to chose a
mechanism ahead at build time, to allow for switching to some newer
stuff ... but what about pre-generated binary versions, which mechanism
shall be used in the default options, which mechanism shall be offered?
With netlink active (sure the proven and better way for the job), you
hit those like Isaac. With netlink disabled, spreading newer technology
to the wide is usually blocked (don't talking about some experts who
know how to build there own BB version).
So why not allowing some innovation, to let the user chose which
mechanism to use? What is wrong with this intention?
I neither want to reinvent the wheel, nor go the udev way to create a
big monolithic block, but I like to get the ability to setup the system
the way I like, without blocking others to use the plug mechanism they like.
--
Harald
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
