Paul Mackerras wrote:
> > Could a single connection to the ppp unit represent multiple unrelated
> > bundles?
> 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.
Fair enough. I just thought it might make for nice multiplexing of
information back to userland, but its certainly not critical.
Thinking about it a bit more I agree that its probably a can
> > 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.
OK, I thought you were talking about having the ppp_generic layer do
some magic kernel-land open() or something. That would be gross.
I'm still unconvinced that supporting transports for which we can't
get an fd is needed at all.. adding socket families is really very
> 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.
Yes, that would be a good thing.
> 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.
Then why not pass back the fd to pppd? In UNIX the basic userland token
representing an object in the kernel is an open file descriptor. What
you're really suggesting is adding a new type of token (the PPP channel
number) which gets passed around much like a file descriptor. While
this isn't impossible, I just don't see the real benefit. It just is
going to add code.
I think the current token could be described as "a file descriptor
willing to perform an ioctl(PPPIOCATTACH)" An improvement would
be to make that ioctl's argument was a file descriptor for the
/dev/ppp we have open. Then we could completely banish the idea
of "channel number" and the code would be considerably cleaner.
What do you think?
> 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.
I can't speak for ultrix or next off the top of my head, but all
the rest definately do. NeXT should also be no problem since BSD4.3
had it. Ultrix may be an issue since it had a lot of BSD 4.1c code
in it, but is it really _that_ important to keep support for things
that old? I've been accused of being a raving DEC fan, and even
_I_ stopped giving Ultrix the time of day years ago.
> 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
> packet boundaries.
I'm just curious where you're anticipating the code re-use coming from.
I'm aware of many protocols built on PPP but PPP-on-async is the only
one I'm aware of that uses those algorithms. Maybe PPP-on-X25? (haven't
read that RFC yet)
I think most any hardware device that needs much of the ppp_async code to
speak PPP would probably be implemented as a tty anyway.