On Wed, Mar 18, 2015 at 02:48 AM, Isaac Dunham said:
Is this manifested as the root device never shows up?
Yes, although we call it the boot device.
As the one who probably posted this, I can comment further:
I've heard of one computer where this was an issue, a couple
years ago; a number of
On Thu, Mar 19, 2015 at 06:02:33PM -0600, James Bowlin wrote:
On Wed, Mar 18, 2015 at 02:48 AM, Isaac Dunham said:
Is this manifested as the root device never shows up?
Yes, although we call it the boot device.
As the one who probably posted this, I can comment further:
I've heard of
Le 18/03/2015 18:41, Laurent Bercot a écrit :
On 18/03/2015 18:08, Didier Kryn wrote:
No, you must write to the pipe to detect it is broken. And you won't
try to write before you've got an event from the netlink. This event
will be lost.
I skim over that discussion (because I don't agree
Le 18/03/2015 20:01, Harald Becker a écrit :
Do you think it matters losing one more event?
Here we are considering the case when fifosvd is killed (say by
admin's error). I understand lost events can be recovered. However there
is one distinctive advantage in detecting immediately the
On Tue, 17 Mar 2015 17:51:39 -0600
James Bowlin bit...@gmail.com wrote:
On Mon, Mar 16, 2015 at 09:55 AM, Natanael Copa said:
On Fri, 13 Mar 2015 13:12:56 -0600
James Bowlin bit...@gmail.com wrote:
TL;DR: the current busybox (or my code) seems to be broken on one
or two systems out
Le 17/03/2015 19:56, Harald Becker a écrit :
Hi Didier,
On 17.03.2015 19:00, Didier Kryn wrote:
The common practice of daemons to put themselves in background and
orphan themself is starting to become disaproved by many designers. I
tend to share this opinion. If such a behaviour is
On 18.03.2015 10:42, Didier Kryn wrote:
Long lived daemons should have both startup methods, selectable by a
parameter, so you make nobodies work more difficult than required.
OK, I think you are right, because it is a little more than a fork:
you want to detach from the controlling
On 18/03/2015 18:08, Didier Kryn wrote:
No, you must write to the pipe to detect it is broken. And you won't
try to write before you've got an event from the netlink. This event
will be lost.
I skim over that discussion (because I don't agree with the design) so
I can't make any substantial
Hi Laurent !
Note that events can still be lost, because the pipe can be broken
while you're reading a message from the netlink, before you come
back to the selector; so the message you just read cannot be sent.
But that is a risk you have to take everytime you perform buffered IO,
there's no
Hi Laurent !
On 18/03/2015 18:08, Didier Kryn wrote:
No, you must write to the pipe to detect it is broken. And you won't
try to write before you've got an event from the netlink. This event
will be lost.
On 18.03.2015 18:41, Laurent Bercot wrote:
I skim over that discussion (because I
Le 18/03/2015 13:34, Harald Becker a écrit :
On 18.03.2015 10:42, Didier Kryn wrote:
Long lived daemons should have both startup methods, selectable by a
parameter, so you make nobodies work more difficult than required.
OK, I think you are right, because it is a little more than a
Hi Didier,
On 17.03.2015 19:00, Didier Kryn wrote:
The common practice of daemons to put themselves in background and
orphan themself is starting to become disaproved by many designers. I
tend to share this opinion. If such a behaviour is desired, it may well
be done in the script (nohup),
On Tue, Mar 17, 2015 at 05:51:39PM -0600, James Bowlin wrote:
On Mon, Mar 16, 2015 at 09:55 AM, Natanael Copa said:
On Fri, 13 Mar 2015 13:12:56 -0600
James Bowlin bit...@gmail.com wrote:
TL;DR: the current busybox (or my code) seems to be broken on one
or two systems out of
Le 16/03/2015 19:18, Harald Becker a écrit :
On 16.03.2015 10:15, Didier Kryn wrote:
4) netlink reader the Unix way
Why let our netlink reader bother about where he sends the event
messages. Just let him do his netlink receiption job and forward the
messages to stdout.
netlink reader:
On Mon, 16 Mar 2015 18:45:26 +0100
Harald Becker ra...@gmx.de wrote:
On 16.03.2015 09:19, Natanael Copa wrote:
I am only aware of reading kernel events from netlink or kernel hotplug
helper.
Where as I'm trying to create a modular system, which allows *you* to
setup a netlink usage,
On 16.03.2015 09:19, Natanael Copa wrote:
I am only aware of reading kernel events from netlink or kernel hotplug
helper.
Where as I'm trying to create a modular system, which allows *you* to
setup a netlink usage, *the next* to setup hotplug helper usage (still
with speed improvement, not
On 16.03.2015 21:30, Natanael Copa wrote:
Does it exist systems that are so old that they lack hotplug - but at
same time are new enough to have sysfs?
Oh, yes! Mainly embedded world.
I suppose it would make sense for kernels without CONFIG_HOTPLUG but I
would expect such systems use highly
On 16.03.2015 22:25, Didier Kryn wrote:
I had not caught the point that you wanted it a general purpose
tool - sorry.
It's a lengthy and complex discussion, not very difficult to miss
something, so no trouble. Please ask, when there are questions.
The netlink reader is a long lived
On Sun, 15 Mar 2015 01:45:05 +0100
Harald Becker ra...@gmx.de wrote:
On 14.03.2015 03:40, Laurent Bercot wrote:
Please take a look at my s6-uevent-listener/s6-uevent-spawner, or at
Natanael's nldev/nldev-handler. The long-lived uevent handler idea is
a *solved problem*.
I know how
On Fri, 13 Mar 2015 13:12:56 -0600
James Bowlin bit...@gmail.com wrote:
TL;DR: the current busybox (or my code) seems to be broken on one
or two systems out of thousands; crucial modules don't get loaded
using hotplug + coldplug. Please give me a runtime option so I
can give my users a
Le 16/03/2015 00:58, Harald Becker a écrit :
We were looking at alternative solutions, so even one more:
3) netlink reader the Unix way
Why let our netlink reader bother about where he sends the event
messages. Just let him do his netlink receiption job and forward the
messages to stdout.
On Sun, Mar 15, 2015 at 08:06 PM, Laurent Bercot said:
kernel guaranties not only atomicity for write operations, but also
for read operations (not in POSIX, AFAIK).
Second sentence of
On 14.03.2015 03:40, Laurent Bercot wrote:
What would you do if your kid wanted to drive a car but said he
didn't like steering wheels, would you build him a car with a
joystick ?
... [base car with wheel steering module replaceable by a joystick
module] ...
... and the next one coming
On 14.03.2015 03:40, Laurent Bercot wrote:
- for reading: having several readers on the same pipe is the land
of undefined behaviour. You definitely don't want that.
... just for the curiosity:
On most systems it is perfectly possible to have multiple readers on a
pipe, when all readers
On 15/03/2015 19:39, Harald Becker wrote:
On most systems it is perfectly possible to have multiple readers on
a pipe, when all readers and writers be so polite to use the same
message size (= PIPE_BUF). On most (but not all Unix systems) the
kernel guaranties not only atomicity for write
On 15.03.2015 20:06, Laurent Bercot wrote:
What most systems do in practice is irrelevant. There is no guarantee
at all on what a system will do when you have multiple readers on the
same pipe; so it's a bad idea, and I don't see that there's any room for
discussion here.
My lead in was:
On 15/03/2015 20:41, James Bowlin wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html :
^
For goodness sake. This appears to be an argument merely for the
sake of having an argument.
This is POSIX.1-2008, the very specification that
On 15.03.2015 20:06, Laurent Bercot wrote:
The behavior of multiple concurrent reads on the same pipe, FIFO,
or terminal device is unspecified.
That is, you can't predict, which process will get the data, but each
single read operation on a pipe (private or named), is done atomic.
Either
On 15/03/2015 23:44, Harald Becker wrote:
There are to many stupid programmers out there, who would try to add
something like that into system management related programs. Couldn't
go worser. Even if it works, at the first glance, it is error prone,
and the next who change message size of one
On 15/03/2015 21:54, Harald Becker wrote:
My lead in was: just for curiosity, and that's it, it works on many systems.
... but I never proposed, doing something like that. It's what my lead in says:
curiosity.
Okay, fair enough. Please let's not do it then. :)
--
Laurent
Hi James!
1) Why argue over something that has already been admitted?
It does not bolster your argument and it does not put in you
a good light.
Keep cool, I know the fears of Laurent.
There are to many stupid programmers out there, who would try to add
something like that into
So, as I'm not in write-only mode, here some possible alternatives, we
could do (may be it shows better, how and why I got to my approach):
1) netlink with a private pipe to long lived handler:
establish netlink socket
spawn a pipe to handler process
write a netlink, no timeout message
On Sun, Mar 15, 2015 at 10:10 PM, Laurent Bercot said:
This is POSIX.1-2008, the very specification that Linux, and other
operating systems, are supposed to implement. It is the authoritative
reference to follow whenever you're designing Unix software. I don't
understand what your objection
On 14.03.2015 03:40, Laurent Bercot wrote:
Hm, after checking, you're right: the guarantee of atomicity
applies with nonblocking IO too, i.e. there are no short writes.
Which is a good thing, as long as you know that no message will
exceed PIPE_BUF - and that is, for now, the case with
Stream-writes [pipe] are not atomic, and your message can theoretically get
cut in half and interleaved with another process writing the same fifo.
Any pipe, whether named or not, IS atomic so long as the datagrams
in question are smaller than PIPE_BUF in size. This has been true
since Day 1, in
TL;DR: the current busybox (or my code) seems to be broken on one
or two systems out of thousands; crucial modules don't get loaded
using hotplug + coldplug. Please give me a runtime option so I
can give my users a boot-time option to try the new approach.
On Fri, Mar 13, 2015 at 02:04 PM,
On 13.03.2015 16:53, Natanael Copa wrote:
I have the feeling (without digging into the busybox code) that making
mdev suitable for a longlived daemon will not be that easy. I suspect
there are lots of error handling that will just exit. A long lived
daemon would need log and continue instead.
El viernes, 13 de marzo de 2015, James Bowlin bit...@gmail.com escribió:
On Fri, Mar 13, 2015 at 08:33 PM, Guillermo Rodriguez Garcia said:
You are talking about a possible bug in the current
implementation. In my opinion this is completely independent
from whether a redesign/architecture
Hi James,
El viernes, 13 de marzo de 2015, James Bowlin bit...@gmail.com escribió:
TL;DR: the current busybox (or my code) seems to be broken on one
or two systems out of thousands; crucial modules don't get loaded
using hotplug + coldplug. Please give me a runtime option so I
can give my
On 13/03/2015 21:32, Michael Conrad wrote:
I stand corrected. I thought there would be a partial write if the
pipe was mostly full, but indeed, it blocks.
Except you have to make the writes blocking, which severely limits
what the writers can do - no asynchronous event loop. For a simple
On Fri, Mar 13, 2015 at 08:33 PM, Guillermo Rodriguez Garcia said:
You are talking about a possible bug in the current
implementation. In my opinion this is completely independent
from whether a redesign/architecture change is required or
wanted.
ISTM you are assuming the redesign will not
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)
On 13.03.2015 23:33, Laurent Bercot wrote:
On 11/03/2015 08:45, Natanael Copa wrote:
With that in mind, wouldn't it be better to have the timer code in
the handler/parser? When there comes no new messages from pipe
within a given time, the handler/parser just exists.
I've thought about that a
On 14/03/2015 01:20, Harald Becker wrote:
I'm using none blocking I/O and expect handling of failure
situations, e.g writing into pipe fails with EAGAIN: poll wait until
write possible with timeout. then redo write
Hm, after checking, you're right: the guarantee of atomicity
applies with
On 13.03.2015 21:32, Michael Conrad wrote:
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
You got the
Hi,
my original intention was to replace mdev with an updated version,
but as there where several complains which told they like to continue
using the the old suffering mdev, I'm thinking about an alternative.
... but the essential argument came from James, fail save operation.
In my last
On 13.03.2015 21:43, Laurent Bercot wrote:
Except you have to make the writes blocking, which severely limits
what the writers can do - no asynchronous event loop. For a simple
cat-equivalent between the netlink and a fifo, it's enough, but
it's about all it's good for. And such a
On 11/03/2015 08:45, Natanael Copa wrote:
The netlink listener daemon will need to deal with the event handler (or
parser as you call it) dying. I mean, the handler (the parser) could
get some error, out of memory, someone broke mdev.conf or anything that
causes mdev to exit. If the child (the
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
On 13.03.2015 10:30, Guillermo Rodriguez Garcia wrote:
There are many configuration options in BB that must be defined at
build time. I don't see why this one would be different.
You can activate both as the default (with cost of some byte overhead of
code size), and let the user of the
2015-03-13 11:19 GMT+01:00 Harald Becker ra...@gmx.de:
On 13.03.2015 10:30, Guillermo Rodriguez Garcia wrote:
There are many configuration options in BB that must be defined at
build time. I don't see why this one would be different.
You can activate both as the default (with cost of some
On Thu, 12 Mar 2015 17:26:38 +
Isaac Dunham ibid...@gmail.com wrote:
On Thu, Mar 12, 2015 at 04:04:41PM +0100, Harald Becker wrote:
No, you misunderstand. Read my proposal below and tell me why this won't
do what you're after, OTHER than the way mdev works now is broken/wrong,
since that
Hi Harald,
2015-03-13 8:25 GMT+01:00 Harald Becker ra...@gmx.de:
On 13.03.2015 00:05, Michael Conrad wrote:
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
On Thu, 12 Mar 2015 17:31:36 +0100
Harald Becker ra...@gmx.de wrote:
Every gathering part grabs the required information, sanitizes,
serializes and then write some kind of command to the fifo. The fifo
management (a minimalist daemon) starts a new parser process when
there is none running
2015-03-13 11:54 GMT+01:00 Harald Becker ra...@gmx.de:
On 13.03.2015 11:25, Guillermo Rodriguez Garcia wrote:
I understand your argument. You are saying that users should be able
to choose at runtime. What I say is that my impression is that most
users belong to one of the following two
On 3/13/2015 9:48 AM, Harald Becker wrote:
On 13.03.2015 12:29, Michael Conrad wrote:
On 3/13/2015 3:25 AM, Harald Becker wrote:
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
On 3/13/2015 3:25 AM, Harald Becker wrote:
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
In that case, I would offer this idea:
On 3/13/2015 3:25 AM, Harald Becker wrote:
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.
Multiple processes writing into
On Thu, 12 Mar 2015 19:05:01 -0400
Michael Conrad mcon...@intellitree.com wrote:
In that case, I would offer this idea:
Thanks. Your pseudo code makes perfect sense to me.
...
3. Then to support the ability to launch mdev connected to a netlink
socket that already exists, and time out
On 13.03.2015 12:41, Michael Conrad wrote:
On 3/13/2015 3:25 AM, Harald Becker wrote:
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
There are interesting technical points in this discussion, but it
turns out to be mostly about philosophy and frustration.
Harald, there are two points in your arguments which make no sense
to me:
Le 12/03/2015 17:31, Harald Becker a écrit :
... because there are people, wo dislike
On 13.03.2015 12:29, Michael Conrad wrote:
On 3/13/2015 3:25 AM, Harald Becker wrote:
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
On 13.03.2015 14:20, Didier Kryn wrote:
There are interesting technical points in this discussion, but it
turns out to be mostly about philosophy and frustration.
ACK :(
Hotplug is KISS, it is stupid, maybe, but it is so simple that you
can probably do the job with a script. The
On 13.03.2015 15:46, Michael Conrad wrote:
I thought pseudocode would be clearer than English text, but I suppose
my pseudocode is still really just English... Maybe some comments will
help.
You can't fix the suffering of your code with some comments ... beside
that, it looks like you
Interrupts ... no trouble, everybody agree you need only one unblocked
interrupt source, but never ask for the detail which one ... :)
Hi Laurent !
I'm sorry if I came across as dismissive or strongly opposed to the
idea.
It was not my intent. My intent, as always, is to try and make
On Wed, 11 Mar 2015 14:30:13 +0100
Harald Becker ra...@gmx.de wrote:
Hi Natanael !
Hi Isaac !
Looks like you misunderstand my approach for the mdev changes ... ok,
may be I explained it the wrong way, so lets go one step back and start
with a wider view:
IMO Busybox is a set of tools,
On Wed, Mar 11, 2015 at 7:02 PM, Harald Becker ra...@gmx.de wrote:
On 11.03.2015 16:21, Laurent Bercot wrote:
I don't understand that binary choice... You can work on your own
project without forking Busybox. You can use both Busybox and your
own project on your systems. Busybox is a set of
Hi Isaac !
On 12.03.2015 02:05, Isaac Dunham wrote:
I just don't think you're quite thinking through exactly what this means.
In which sense? Let me know, what I got wrong. I'm a human, making mistakes,
not a perfect machine.
It seems like you want to force everyone who uses mdev to use a
Hi !
To Michael:
Don't be confused, Natanael provided an alternative version to achieve
the initial device file system setup (which isn't bad, but may have it's
cons for some people on small resource constrained systems of the
embedded world). So I left it out for clarity ... but still may
On Thu, Mar 12, 2015 at 6:00 PM, Harald Becker ra...@gmx.de wrote:
Hi Laszlo !
So why don't you write such a binary wrapping busybox then and other
things? I think KISS principle still ought to be alive these days.
Not to mention, Denys already cannot cope with the maintenance the
way that
Hi Laszlo !
So why don't you write such a binary wrapping busybox then and other
things? I think KISS principle still ought to be alive these days.
Not to mention, Denys already cannot cope with the maintenance the
way that it would be ideal. For instance, some of my IMHO serious
bugfixes are
On Thu, Mar 12, 2015 at 04:04:41PM +0100, Harald Becker wrote:
Hi Isaac !
On 12.03.2015 02:05, Isaac Dunham wrote:
I just don't think you're quite thinking through exactly what this means.
In which sense? Let me know, what I got wrong. I'm a human, making mistakes,
not a perfect machine.
On 12/03/2015 18:26, Isaac Dunham wrote:
[1] The format proposed by Laurent uses \0 as an line terminator;
I think it might be better to use something that's more readily
generated by standard scripting tools from uevent files, which would
make it possible to use cat or env to feed the mdev
Hi Natanael !
I assume that you are talking about named pipes (aka fifos)
http://en.wikipedia.org/wiki/Named_pipe
Ack, fifo device in the Linux / Unix world.
Why do you need a hotplug helper spawned by kernel when you have a
netlink listener? The entire idea with netlink listener is to
The question I was asking was only about this:
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
Hi Laurent !
Out of curiosity: what are, to you, the benefits of this approach ?
What are the benefits of preferences? ... good question!? ;)
Does it actually save you noticeable amounts of RAM ?
May be a few bytes ... noticeable? what is your level to noticeable
here? ... otherwise I
On 11/03/2015 14:02, Denys Vlasenko wrote:
But that nldev process will exist for all time, right? That's not elegant.
Ideally, this respawning logic should be in the kernel.
Well there is already a kernel-based solution: hotplug.
Sure, it's not serialized, but it's there. If you want
I suppose it's time to dig out code from the secret archives of my
secret lair again. Someone named Vladimir Dronnikov called this ndev
and proposed it as a patch to Busybox in 2009. I dug it out and
separated it from Busybox, and probably made some other changes I don't
remember, for some
Hi Denys !
mdev rules are complicated already. Adding more cases
needs adding more code, and requires people to learn
new mini-language for mounting filesystems via mdev.
Think about it. You are succumbing to featuritis.
...
This is how all bloated all-in-one disasters start.
Fight that
Hi William !
On 11.03.2015 17:03, William Haddon wrote:
I suppose it's time to dig out code from the secret archives of my
secret lair again. Someone named Vladimir Dronnikov called this ndev
and proposed it as a patch to Busybox in 2009. I dug it out and
separated it from Busybox, and probably
On 3/11/2015 9:30 AM, Harald Becker wrote:
So how can we avoid that unwanted parallelism, but still enable all of
the above usage scenarios *and* still have a maximum of code sharing
*and* a minimum of memory usage *without* delaying the average event
handling too much?
The gathering parts
Hi Isaac !
Agreed, whole-heartedly.
I just don't think you're quite thinking through exactly what this means.
In which sense? Let me know, what I got wrong. I'm a human, making
mistakes, not a perfect machine.
Agreed.
But I would include hotplug daemons under etc.
I used etc. so add
On 11.03.2015 22:44, Michael Conrad wrote:
What specifically is the appeal of a third approach which tries to
re-create the kernel netlink design in user-land using a fifo written
from forked hotplug helpers?
You mix things a bit.
My approach allows to either using netlink or kernel hotplug
Hi Michael !
On 11.03.2015 22:44, Michael Conrad wrote:
I'm interested in this thread, but there is too much to read. Can you
explain your reason in one concise paragraph?
One paragraph is a bit to short, my English sucks, but I try to
summarize the intention of my approach in compact steps
On Tue, 10 Mar 2015 17:26:20 +0100
Harald Becker ra...@gmx.de wrote:
First look at, what to do, then decide how to implement:
mdev needs to do the following steps:
- on startup the sys file system is scanned for device entries
You don't want scan sysfs for devince entries. Instead you
On Tue, 10 Mar 2015 17:56:59 +
Isaac Dunham ibid...@gmail.com wrote:
Now, a comment or two on design of mdev -i and the netlink listener:
I really *would* like there to be a timeout of some sort; in my
experience, 1 second may be rather short, and 5 seconds is usually
ample.
Just one
On Tue, 10 Mar 2015 17:56:59 +
Isaac Dunham ibid...@gmail.com wrote:
On Tue, Mar 10, 2015 at 01:37:41PM +0100, Harald Becker wrote:
Hi Laurent !
... I dislike the idea of integrating early init functions into mdev,
because those
functions are geographically (as in the place where
Hi Laurent !
1) Starting up a system with mdev usually involves the same steps to
mount proc, sys and a tmpfs on dev, then adding some subdirectories
to /dev, setting owner, group and permissions, symlinking some
entries and possibly mounting more virtual file systems. This work
need to be
Hi Harald,
I'm sorry if I came across as dismissive or strongly opposed to the idea.
It was not my intent. My intent, as always, is to try and make sure that
potential new code 1. is worth writing at all, and 2. is designed the
right way. I don't object to discourage you, I object to generate
On Tue, Mar 10, 2015 at 01:37:41PM +0100, Harald Becker wrote:
Hi Laurent !
... I dislike the idea of integrating early init functions into mdev,
because those
functions are geographically (as in the place where they're performed) close
to mdev,
but they have nothing to do with mdev
Hi,
getting hints and ideas from Laurent and Natanael, I found we can get
most flexibility, when when try to do some modularization of the steps
done by mdev.
At fist there are two different kinds of work to deal with:
1) The overall operation and usage of netlink
2) Extending the mdev.conf
Hi Natanael !
I am interested in a netlink listener too for 2 reasons:
- serialize the events
- reduce number of forks for perfomance reasons
My primary intentions.
That is, I want to auto fork a daemon which just open the netlink
socket. When events arrive it forks again, creating a
On Sun, 08 Mar 2015 16:10:32 +0100
Harald Becker ra...@gmx.de wrote:
Hi,
I'm currently in the phase of thinking about extending the functionality
of mdev. As here are the experts working with this kind of software, I
like to here your ideas before I start hacking the code.
...
2) I
On 09/03/2015 09:41, Natanael Copa wrote:
What I'd like to do is:
change mdev to:
- be able to read events from stdin. same format as from netlink socket.
The thing is, the format from the netlink socket is a bit painful to parse;
the hard part of netlink listeners isn't to actually listen
Hi,
I'm currently in the phase of thinking about extending the functionality
of mdev. As here are the experts working with this kind of software, I
like to here your ideas before I start hacking the code.
I like to focus on the following topics:
1) Starting up a system with mdev usually
Hi Harald !
1) Starting up a system with mdev usually involves the same steps to
mount proc, sys and a tmpfs on dev, then adding some subdirectories
to /dev, setting owner, group and permissions, symlinking some
entries and possibly mounting more virtual file systems. This work
need to be
96 matches
Mail list logo
