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