On Fri, 04 Feb 2000, jamal wrote:
> hehe. Same here. Havent heard from Mark Spencer or Paul Mackerras. It
> would be nice to hear from them.
Yes, sorry I haven't jumped in earlier. Here's what I think:
- Forget the old (2.2) ppp driver, we'll backport the 2.3 driver to 2.2
rather than doing major surgery to the 2.2 driver.
- At the moment, with the channels stuff, pppd needs to be able to have a
fd to each channel which it can do read/write/poll/ioctl on, and the
channel has to specify which ppp unit it is to be attached to when it is
registered. I now think that we should do it a bit differently in order
to minimize the amount of duplicated code in each channel.
In order to be able to do multilink, pppd needs to be able to talk to each
channel separately as well as to the ppp unit (which represents a bundle),
and this is why pppd needs to be able to do read/write/poll on the channel.
I plan to rearrange the code so that it will instead talk to the channel
through an open instance of /dev/ppp. We'll make it so that when a channel
registers itself, it gets given a channel number which can be passed to
pppd. Pppd will open /dev/ppp and use an ioctl to connect that instance
to the channel. It can then use another ioctl to connect that channel to
a ppp unit.
This way, pppd doesn't have to know how to get hold of a file descriptor
for talking directly to a channel, it just needs to know the channel
number. We can then either have a separate program for the discovery or
have a plugin to do the discovery. If we have a separate program, it
just needs to tell pppd the channel number (there are several ways we can
do this, e.g. via connect/disconnect scripts, or the discovery program
invoking pppd, or the discovery program can talk to pppd through a pair of
pipes or a socket). Probably there should be a UID associated with the
channel to make sure I can't steal the channel you just set up.
- I plan to pull out the async encapsulation stuff into a library so that
other channels can use it too. Thus ppp_async.c should end up with very
little in it other than stuff for implementing the line discipline and
talking to the serial driver.
- I am not so keen on the idea of having one process handling thousands of
connections - don't poll and select get very inefficient if you have
thousands of file descriptors? With that many fds, not only does the
setup cost rise, but the poll/select will wait for a shorter time on
average, so you pay the setup cost more often. On the other hand, having
a thousand daemons means 8MB of kernel space gone just for the kernel
stacks and process structures. We should maybe ask Alan Cox what the best
Certainly for moderate numbers of connections the process-per-connection
model is good - if the daemon dies, you only lose one connection, and if
you want to kill a connection, there is an identifiable process to send a
I hope to spend a fair bit of the coming week on ppp hacking. :-)
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
Linuxcare. Support for the revolution.