Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: kerneld/request-route | Date | Wed, 3 Jul 1996 13:22:13 -0400 | From | "Eric Schenk" <> |
| |
Alan Cox <alan@cymru.net> writes: > Bo Johansson <bo.johansson@mbox2.swipnet.se> writes: >> But to use diald, if you are using PPP then you have to add SLIP >> to your kernel and run yet another daemon and still run kerneld >> (if you want to load modules automatically), am I right?. >> That doesn't seem like a good solution to me. > >So teach diald to also know how to watch for PPP over a tty/pty pair
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
| ![\](/images/icornerr.gif) |