My first thought on seeing this was that this would require you to
implement the entire PPP protocol inside of diald. (This is done
for SLIP inside of diald right now, but slip is dead simple. Maybe 20 lines
of code). Thinking about a bit more, I'm not so sure. It might be possible
to just attach a tty to a PPP link, tell the PPP link it is up, and then
just eat the characters that come over the link (ignoring the protocol).
To actually see what packets are hitting the link you could then
just put a SOCK_PACKET tap onto the PPP device and watch that.
However, this does twice the work as a SLIP device for every packet
that comes across (you must read the packet as encoded by PPP, and
you must read the packet off of the tap).
Also, it may be the case that it is sufficient to only implement a small
subset of the PPP protocol, but I'd have to try it to see.
As the sentiment expressed by Bo Johansson: I'm curious, are you objecting
more to the idea of loading an extra modul into the kernel (SLIP),
or to having an extra user space process?
If it's the former then note that the proposed fixes to make kerneld
actually work properly amount to requiring you to have the dummy
module loaded.
If it's the later, then why aren't you also objecting that kerneld
doesn't perform, say, the functions of inetd, which also starts up
user space processes on demand?
To those who feel that diald is too complex, please suggest how it can
be simplified, but make sure you have thought about all the failure
modes before you post your suggestion. Diald did not happen by accident,
it has developed over a period of about two years now. The initial versions
of diald looked a lot like some of what I have seen suggested here recently.
It was a lot simpler and smaller. It was also a lot more prone to bizzare
failure modes. There are reasons behind every design decision that was made.
I'm not entirely happen with every trade off that was made, but at the
moment I don't know of a better set of design trade offs.
-- eric