On Mon, 07 Feb 2000, Mitchell Blank Jr wrote:
> 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
No, I don't see any point in allowing this and it would complicate things.
If you want to control multiple bundles you open /dev/ppp several times
and attach the individual fds to the individual bundles.
> > 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.
> 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
Sure. I think my point was more that if there are some transports where
we don't have a fd, we can accommodate them too. There's also the point
that my design relieves each channel from having to provide read() and
write() methods for sending and receiving PPP frames on that channel.
Instead that code is there once in ppp_generic.c.
> kernel grab it (instead of going through the normal open(2) path)
Maybe we have a misunderstanding here. The way I see it that the
discovery stuff will use open or socket or whatever to get hold of an fd,
then do an ioctl to say "become a PPP channel" and get back a channel
number. This channel number gets passed to pppd which then does the ppp
stuff over it. Most likely the original fd needs to be kept open while we
are doing ppp over the channel.
> 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.
Using unix-domain sockets and the control message stuff, you mean? I must
admit I've never actually used that. I could cheerfully have that in a
pppd plugin but I would be hesitant about using it in pppd proper unless I
can be sure it is supported on all the unices that pppd runs on.
> 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.
If it's a library, you don't have to use it but you can if you want to.
Anything that wants to make a stream where it doesn't need to preserve
packet boundaries would probably want to use the async encapsulation, at
least to the extent of escaping ~ and }, and putting in ~ to mark the
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
Linuxcare. Support for the revolution.