Well, I've poked at this a little this evening.
See
https://github.com/idunham/busybox
(in branch mdev) if you're curious about details.
Hi Isaac,
Nice job!
A few comments:
- Original mdev relies on getenv/putenv to handle environment
variables; that's okay, because it's a short-lived
On 20/03/2015 17:47, Isaac Dunham wrote:
I'm not sure I follow you on the malloc/free/realloc bit:
-as far as I know, getenv() does not malloc() anything, but returns
the numeric value of a pointer within char ** environ
getenv() is not a problem indeed. (Reading is rarely a problem,
it's
On Fri, Mar 20, 2015 at 10:04:19AM +0100, Laurent Bercot wrote:
Well, I've poked at this a little this evening.
See
https://github.com/idunham/busybox
(in branch mdev) if you're curious about details.
Hi Isaac,
Nice job!
Thanks.
A few comments:
- Original mdev relies on
On 16.03.2015 19:49, Natanael Copa wrote:
netlink reader | tee /dev/ttyX | device operation handler
This looks good to me.
If you want avoid that this netlink reader in your example is in memory
at all times, then feel free to use my netlink socket activator to
activate it.
On Fri, Mar 20, 2015 at 10:09:59PM +0100, Laurent Bercot wrote:
On 20/03/2015 17:47, Isaac Dunham wrote:
I'm not sure I follow you on the malloc/free/realloc bit:
snip
-according to the manpage, putenv() does not copy the string, but
modifies environ by inserting a pointer to the string.
If
On 20.03.2015 21:28, V.Krishn wrote:
The concept of a simple netlink reader daemon seems nice.
But would seem extra to having another reader that reads this reader.
The concept of whole /sys tree is being re-done, even if its just not
visible(memory). I could add/suggest few changes.
Please
On Mon, Mar 16, 2015 at 05:18:27PM +0100, Natanael Copa wrote:
Ininitial mdev -i patch for busybox which reads messages from stream
(so it should work with your fif manager):
http://sprunge.us/ZjLK
(also attached)
A few notes:
- Its completely untested but it compiles
- it
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
On Sun, 15 Mar 2015 21:46:42 +0100
Harald Becker ra...@gmx.de wrote:
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
On 16.03.2015 08:16, Natanael Copa wrote:
This give me exactly what I am interested in: a hotplug handler that is
fast while keep memory consumption at a minimal during long periods
with no events.
This is the essential of your message, I would give *you* the expected
result, but not to
On Mon, Mar 16, 2015 at 05:18:27PM +0100, Natanael Copa wrote:
Ininitial mdev -i patch for busybox which reads messages from stream
(so it should work with your fif manager):
http://sprunge.us/ZjLK
(also attached)
A few notes:
- Its completely untested but it compiles
- it needs the
Hi,
On Sun, 15 Mar 2015 21:46:42 +0100
Harald Becker ra...@gmx.de wrote:
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
On 03/15/2015 12:16 PM, Laurent Bercot wrote:
On 15/03/2015 15:52, Natanael Copa wrote:
I have simplified the long-time living netlink listener more by
forwarding the netlink socket and letting the handler read
directly from netlink. This factorize out the pipe and remove the need
of any micro
On Sun, 15 Mar 2015 17:16:37 +0100
Laurent Bercot ska-dietl...@skarnet.org wrote:
On 15/03/2015 15:52, Natanael Copa wrote:
I have simplified the long-time living netlink listener more by
forwarding the netlink socket and letting the handler read
directly from netlink. This factorize out
On Mon, 16 Mar 2015 18:13:17 +0100
Harald Becker ra...@gmx.de wrote:
On 16.03.2015 08:16, Natanael Copa wrote:
This give me exactly what I am interested in: a hotplug handler that is
fast while keep memory consumption at a minimal during long periods
with no events.
This is the
On 16.03.2015 18:13, Harald Becker wrote:
This is the essential of your message, I would give *you* the expected
result, but not to everybody else.
Sorry, bad typo :( - s /I/it/
This is the essential of your message, *it* would give *you* the
expected result, but *not* to *everybody* else.
On 16.03.2015 19:49, Natanael Copa wrote:
netlink reader | tee /dev/ttyX | device operation handler
This looks good to me.
If you want avoid that this netlink reader in your example is in memory
at all times, then feel free to use my netlink socket activator to
activate it. Otherwise, please
On Sun, 15 Mar 2015 02:30:33 +0100
Harald Becker ra...@gmx.de wrote:
Hi Isaac !
On 14.03.2015 08:10, Isaac Dunham wrote:
Basic concept is that it creates a fifo, and treats the success of mkfifo
as a lock to determine whether it's the daemon or a writer.
If it's the daemon, it will
Harald,
On Fri, 13 Mar 2015 10:04:57 +0100
Harald Becker ra...@gmx.de 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
On 15/03/2015 14:29, Natanael Copa wrote:
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
On 15/03/2015 15:52, Natanael Copa wrote:
I have simplified the long-time living netlink listener more by
forwarding the netlink socket and letting the handler read
directly from netlink. This factorize out the pipe and remove the need
of any micro protocol.
As I wrote in another message,
On Thu, 12 Mar 2015 17:51:00 +0100
Laurent Bercot ska-dietl...@skarnet.org wrote:
On 12/03/2015 16:19, Natanael Copa wrote:
netlink listener code that needs to be in memory all the time:
http://git.alpinelinux.org/cgit/ncopa/nldev/tree/nldev.c
A few comments:
...
- spawn_handler():
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
On Thu, Mar 12, 2015 at 05:51:00PM +0100, Laurent Bercot wrote:
On 12/03/2015 16:19, Natanael Copa wrote:
netlink listener code that needs to be in memory all the time:
http://git.alpinelinux.org/cgit/ncopa/nldev/tree/nldev.c
A few comments:
[...]
- It may be worth it to write functions
Hi Isaac !
On 14.03.2015 08:10, Isaac Dunham wrote:
Basic concept is that it creates a fifo, and treats the success of mkfifo
as a lock to determine whether it's the daemon or a writer.
If it's the daemon, it will
fork;
in the child:
exec the parser with the fifo as stdin
in the parent:
On 14/03/2015 20:23, Rich Felker wrote:
Could you elaborate on how you measure that? With musl only the parts
of stdio you actually use will be linked, and use of exit does not
result in linking of any additional code, since the startup code has
to call exit(main(...)) anyway. In any case exit
On Sun, Mar 15, 2015 at 01:22:35AM +0100, Laurent Bercot wrote:
On 14/03/2015 20:23, Rich Felker wrote:
Could you elaborate on how you measure that? With musl only the parts
of stdio you actually use will be linked, and use of exit does not
result in linking of any additional code, since the
On Thu, Mar 12, 2015 at 05:51:00PM +0100, Laurent Bercot wrote:
On 12/03/2015 16:19, Natanael Copa wrote:
netlink listener code that needs to be in memory all the time:
http://git.alpinelinux.org/cgit/ncopa/nldev/tree/nldev.c
- It may be worth it to write functions similar to die(), edie()
On Fri, Mar 13, 2015 at 08:23:49AM +0100, Natanael Copa wrote:
On Thu, 12 Mar 2015 22:38:10 +0100
Harald Becker ra...@gmx.de wrote:
snip
So my question to this:
What is the sense of this?
What do you want to express with this?
Show with an example the idea a possible way to solve the
On Thu, 12 Mar 2015 22:38:10 +0100
Harald Becker ra...@gmx.de wrote:
Hi Natanael,
I prefer finishing planning and creating a functional complete
structure, before hacking code, so I do not see any benefits, to dig
into your code at the moment, don't see any question that could be
Hi,
I have modified nldev[1] to instead of just executing mdev on kernel
events it will forward the event to a helper program via pipe. If
helper program exits (normally due to timeout), it will respawn it as
needed.
netlink listener code that needs to be in memory all the time:
On 12/03/2015 16:19, Natanael Copa wrote:
netlink listener code that needs to be in memory all the time:
http://git.alpinelinux.org/cgit/ncopa/nldev/tree/nldev.c
A few comments:
- disableoom(): it's a generic operation for any daemon you don't
want to have killed, so you can factorize it:
http://git.alpinelinux.org/cgit/ncopa/nldev/tree/nldev-handler.c
- child(): the parent is blocking as long as the child is running -
this is not safe if a user registers a bad-behaved helper. The
parent should be able to kill the child after a timeout.
- line 76: especially since you're
33 matches
Mail list logo
