> I think that for PPPoE at least sockets (of some form) are the way to
> go, because with a sockets approach we have code that maintains
> consistent semantics.
I agree, especially if you're running a PPPoE session server, where
you need hundreds of simultaneous sessions demuxed.
> This does raise the issue of how options are treated wrt modules; we
> could allow modules to register their own option namespace (e.g.:
> allow for channel specific options such as "pppoe.ac_name").
Uh, pppd modules can already register options.
> Thus we would allow for each channel module to register an options
> namespace and functions for connect, disconnect, and "devicename"
This has already been discussed among the PPPoA folks (i.e.
mostly Jens and myself :-) Basically we need to add a
few hooks to pppd-2.3.11 to allow all the tty-specific
code to be worked around by a module.
> > We should merge also the PPP over ATM already implemented using Michals
> > idea.
> I'd appreciate it if somebody would send me pointers to relevant
> code so I can see what things are like in PPPoATM land (and how they
> relate to PPPoE).
It's a little rough (i.e. it currently takes the "big stick" approach
to making pppd work instead of the module-style detailed above)
The kernel-side stuff (which is my fault) shows how simple adding
a protocol to the ppp_generic stuff can be. Ignore the ATTACH_ENCAPS
ioctl - I was smoking something when I decided I needed that...
really setting the encapsulation should be a seperate ioctl (like
setting the tty options in ppp_async works)