Paul Mackerras wrote:
> 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),
Could a single connection to the ppp unit represent multiple unrelated
> 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
I don't think this is a big deal - for many potential transports, its
perfectly natural to operate on them as a file descriptor. Making the
kernel grab it (instead of going through the normal open(2) path)
will only complicate matters. Then again, I'm of the opinion that
adding new socket families for new pure-PPP transports (PPPoE being
the obvious one) is No Big Deal(tm), which doesn't seem to be the
common viewpoint around here.
As for teaching pppd to "get hold of a file descriptor" I worked a lot
today at making that stuff modular... I've still got a little work
to do, but I'll share a patch with the rest of the class tommorrow.
Hopefully you'll find it fit for inclusion with the next pppd, which
will make PPPoATM and PPPoE at least a lot easier to install.
> Probably there should be a UID associated with the
> channel to make sure I can't steal the channel you just set up.
Its things like this that make me really like the socket-family model.
When you have a file descriptor you have a nice automatically reference-
counted token that you can pass among user-space programs.
> - I plan to pull out the async encapsulation stuff into a library so that
> other channels can use it too.
What of the async encapsulation stuff is needed by other channel types?
Most of the obvious ones (PPPoATM, PPPoE, PPTP, L2TP) are packet-based
and won't need any of that code at all. I can't think of any other
encapsulations that would need control-character escaping and the like.
> - 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?
Yes, but an async-signal+poll method can deal with tens of thousands
of fds quite comfortably.
> With that many fds, not only does the
> setup cost rise,
No per-loop setup costs with a signal-based model. The only time you
need to fall back on a poll is in the unlikely event that you've
overflowed the signal queue - in that case you probably have loads of
fds that need servicing, so poll is actually rather efficient.
> On the other hand, having
> a thousand daemons means 8MB of kernel space gone just for the kernel
> stacks and process structures.
Exactly. Plus managing shared resources like dyanmic IP pools is