You raise some good points - standardizing the iterface for all the
imaginable user space kernel support programs that one could imagine
is definitely a good thing. I know that there is some desire to move
all the routing to user space (Alexey and I have chatted briefly
about this possibility, and multicast routing is already in user
space if i understand correctly), as well as anything else that could
potentially involve really big tables. So, how to go about doing it
in an orderly fashion.... Here's my two cents worth:
1) it is really obnoxious to run around and find pieces from various
sources. so, i would love to see someone/me/bjorn volunteer to keep
a package of all such kerneld-related utilities together in one spot,
and possibly even distribute it with the kernel itself.
2) i have no moral or ethical objections to these kerneld-related
programs being dependent on libc. i don't really see the point
in jumping through hoops to avoid using libc for user-space processes,
even if they are communicating with the kernel.
3) i don't believe the kernel should ever REQUIRE the existance of
such programs (although obviously it should use them if available and
the use of these programs adds some functionality to the kernel as a whole)
4) having kerneld autoload such utilities is a wonderful idea. it could
be done a number of ways, but i'm partial to something similar to the
manner in which inetd works. any thoughts? bjorn and i have chatted
a bit about the pros and cons of combining arpd with kerneld, and
we agreed that separate is probably best. but having kerneld autoload
arpd, well, i rather like that.
i should have some more time to devote to this next week, so i'll
be in touch shortly. did you have something specific in mind, matthias?