Revisiting threaded udevd

[Alan Jenkins <alan-jenkins@tuffmail.co.uk>]

I have some time to look at this again now.

I think Scott was right to question the way I handled running external
programs.  The "udev-exec" daemon takes a fair amount of code, and it's
not easy to justify.  I also suspect it would have bad effects on
process placement on many-cpu systems.

That said, "udev-exec" does actually improve performance.  I would
explain this as fork() being more efficient in processes with a smaller
memory map.  A multi-threaded udevd requires additional address space
for each thread stack.

So I'm going to try limiting the number of threads.  E.g. a maximum of 2
+ 2N running threads.  "Running" is defined as "not waiting for an
external program".  The current limit on total threads would still be
applied.   The hope is to reduce the number of threads, while still
allowing lots of parallel IO.  Reducing the number of threads should
help reduce overheads in general.

The second reason for "udev-exec" was the "close on exec" problem of
leaking irrelevant file descriptors to helper programs.  Scott suggests
that I make udev depend on the latest system calls, e.g. pipe2(), in
2.6.27.  But I want to be able to run older kernels for testing etc!  So
I'll take advantage of the new calls where available.  On older kernels,
I'll use an RW lock to make e.g.

pipe();
fcntl(fd, F_SETFD, FD_CLOEXEC)

atomic against fork().


For completeness, the last reason for udev-exec was more convenient
timeouts.  Without udev-exec I expect they'll be a bit clunky, but it
can be done.

Regards
Alan