Hi Timo !
On 16.03.2015 07:23, Timo Teras wrote:
My take on this is that you are designing an abstract server to be
usable by several things. However, in our case it would be used only
by one thing. Thus adding complexity by introducing one more
component than needed. Not everyone wants to use fifo supervisor.
Yes, it might make sense if everyone used it. But who's now trying
to make people do things his way?
The fact is, you will always use it's functionality, when you use
netlink reader. It has either be included in the netlink reader process
(may be with slight optimization to to choosing some defaults), or split
in a separate thread. I did the later, making it reusable for other
purposes, at no extra cost.
I would happier with solution to a specific problem that is simple
to install, than solution to all that requires additional changes
everywhere.
May be it is confusing, as we talked about the functionality, but
installing / using this is in nothing different. Ok, assuming, you don't
think it is a problem adding e.g. an extra option to a command line, to
activate netlink operation, else you would stay at hotplug helper.
Anything wrong with this?
The startup of the smal supervisor process is done automatically, when
required by other functions, but stays as a long lived service, until
killed.
Granted the idea is nice. But what happened with inetd? No one uses
it real servers anymore. It is usable only in special embedded
solutions. I see fifosvc the same.
inetd is a bit special, it tries to replace several other operations of
tcpsvd and udpsvd. fifosvd is just comparable operation of tcpsvd for
pipes or named pipes, instead of incoming TCP requests. Everybody using
pipes or named pipes and wants to startup the consumer process only on
demand, may benefit from that.
It'd be usable in special embedded solutions, but not in a real
distribution. The idea of it is intriguing, though.
Why not usable in "real distributions"? I'm running on Linux Mint, a
real distribution I assume, using pipes and named pipes for different
purposes. Not all but several of them could benefit from on demand
startup of the pipe consumer process.
It is the wider view, who gives that sense. Not the operation, stuck on
only looking for the netlink operation. The handling / usage will be the
same, except you will see a small extra process in your process list.
I have not followed all the discussion. But does it handle also all
the named pipe details correctly? E.g. when named pipe has been
connected, and then disconnected by reader. All writers will get
errors like EPIPE until you close and recreate it.
The trick is, this won't happen, as one of the primary jobs of that
piece of code is, to hold the pipe open, so it does not vanish, when
others close there copy of the descriptor (buffer space is only assigned
by the kernel when required). For the read end of the pipe it is handled
by the supervisor job, independent of private or named pipe. For the
write end it is only done for named pipes, leaving the handling of the
pipe to the writer process (intentional usage).
The intention of fifosvd (or may be call it pipesvd), is to be of
general usability, for different purposes. If I missed something, then I
apologize. Let me know what's missing.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
