Subject: PPP thoughts
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 10/28/1999 19:57:03
I've been corresponding with someone from Waterloo (you know who you
are, speak up if you care to) about my PPPoE code. Falling out of this
discussion are some thoughts on PPP in general that I'd like to bounce
off you people.
Specifically, it seems to me that the PPP setup scheme is rather
backward. You don't tell a PPP device to attach to a tty line, you
tell a tty line to have a PPP device attach to it. This strikes me as
rather upside down, and in particular it makes PPPoE comparatively
Mind you, I can see why this was done, because it's easy to get a
handle (an open fd, in this case) on a tty line, and it isn't on a ppp
interface. But when binding a ppp interface and an Ethernet interface
for PPPoE, neither one can give userland a file descriptor.
What would the general reaction be to reworking the PPP glue so that
each PPP device can be reached by a file descriptor (perhaps a
special-purpose socket, perhaps an open device node - the details don't
really matter), and then have backend modules that the PPP device can
talk to - one for ttys, one for Ethernet? Possibly even a
pseudo-device backend, the PPP-backend analog of the tun and pty
drivers, which would allow easy and clean development of userland PPP
implementations (both for people who want userland PPP in general, and
for people playing with doing PPP over unusual media)?
Obviously, this is not a full-fledged design proposal. I'm looking for
ideas at this point, just trying to find the correct unifying
abstraction underlying PPP-over-serial, PPPoE, and whatever PPPoXXX may
come down the pike in the future.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B