> This is not posted to l-k because i didnt see the need for it.
Probably a good idea. If it is going to happen on a vger list
it should realy be linux-ppp
> Hopefully, the result here is that we have a solution quickly decided so
> we can submit into 2.3
I really don't see why the channels stuff in 2.3 shouldn't just
stay as is - it's really very clean. The real work that needs
to be done is to pppd to support plugins that deal with different
channel types better.
> The issue as i see it:
> Too many "PPP over X" type protocols (PPPOE, L2TP, PPP over ATM, PPP
> over SONET etc) and there will be a lot more coming probably.
...PPTP, ISDN-PPP (is that using the new ppp_generic code yet?),
RFC 1598 (PPP-over-X25), RFC 1973 (PPP-over-Frame), RFC2363
> The problem IMO:
> Too many solutions; same end goal --> kernel cluttering.
The problem as I see it is just that more things need to
convert to the channels stuff (ppp_generic and friends)
> -No changes required for any PPP/d (user/kernel)
I don't see this an advantage - recent pppd's have a plugin mechanism
which could make these changes very clean (see the PLUGINS
file in a recent pppd). All that is really needed is the tty-specific
stuff in pppd to have hooks put around it so it can be supplanted
easily by non-tty variants. Then each PPP-o-X can just have
its own module.
The only challenge is getting a firm enough grasp on all the
pppd code that deals with ttys so the small surgical changes
can be made without upsetting other ports. I haven't had
time to divine this level of understanding of all those
twisty little passages.
> -has both the discovery and data switcing encap/decap into the kernel
> -PPPd talks to a brand new socket family (created for PPPOE).
> Code size in the kernel (At the moment about 60k)
> This includes also the server part.
> Contribution from the socket addition: about 30% of this
I think this is fine. PPPoE is a full-fledged protocol with all
the mux/demux needs that implies. It's just going to be a
little large if you want a flexible implementation. None of
that has anything to do with the choice of ppp implementation.
Look at the ppp-o-atm code - since the VCC mux/demux is handled
by the higher layer (it's just over a standard PPP socket)
the code to use the ppp_generic channel interface is almost
trivial. If I had to rewrite it to emulate a tty interface
not only would the performance suck eggs, but the code would
be much larger.
PPP is a packet-oriented interface and the current (2.3)
ppp_generic stuff reflects that nicely.
> does not use the tty interface. Uses the channel interface;
> -Bloats the kernel.
Again, wrong. For a simple to implement protocol it bloats
the kernel less than ppp_async does.
> -The socket use could become a maintainance nightmare
> (claim: it looks very clean at the moment).
It's not a maintence nightmare. Quite the opposite - using
a socket family gives you all the socket infastructure (like
module auto-load) for free.
> -Creating a whole socket family for just PPPOE is a bad idea
I don't think so - it has its own addressing, so it needs
its own address family.
> 1. pppoxd negotiates a connection and identifies parameters
> eg in PPPPOE the sid and remote MAC address for the connection.
> 2. pppoxd opens a connection to the pppox interface.
> to grab a fd which will be used by pppd.
> eg if the interface used was a socket then for pppoe,
> this determines the definition of sockaddr_pppoe.
> 3. pppoxd hands-off the fd to pppd.
Why make a new pppoxd? Wouldn't it be easier to just use a pppd plugin?
> WHAT Needs to be decided
> We are all curently in violent agreement that discovery should be in
> user space (includes Michal).
Then I'll be the violent dissenter, I guess. I don't think discovery
is analagous to ARP (which also has a right to be in the kernel, IMO)..
it's more analagous to TCP connect.
Michal's code provides very clean socket semantics.. I think those
should be preserved. When I looked at the code months ago there
were a bunch of implementation problems (HZ=100 assumptions,
needs a better hashed structure for holding connections (look
at tcp code), didn't properly verify MAC on incoming data
frames, etc) I spent a couple hours at a local diner with
a printout of the pppoe code doing an audit and came up with a
dozen or so suggested improvements.... then I managed to
lose all my notes before doing anything with them :-(
> The main decision to make is what interface should PPPd be
> talking to? For 2.2, the only viable solution is the tty one.
I think we should just write off 2.2 - 2.4 is on the way.
If someone wants all these PPP-o-X things in 2.2 that badly
then they should do a back-port of ppp_generic and friends.
> So what should be the device that pppd talks to? Is it a new socket
> family, tty device, a new char device etc.?
Depends on the "X" in PPP-o-X!
tty: can talk to a tty device just like now
PPPoE: new socket family
PPPoA: ATM_PVC socket
> Note that we currently have a limitation in pppd in that it is very
> friendly to ttys. A small change will be required in the pppd daemon.
> No changes in the kernel PPP.
OK, now you're talking sense. :-)
> I propose addition of a new syntax to the pppd options:
> "channelname <channelname>" eg "channelname l2tp"
> The pppd code should check for this syntax (which is mutually
> exclusive with the devicename option). When this option is passed,
> any assumptions that pppd is talking to a tty device are nullified.
I think this can all be handled by the plugin architecture. We just
need a hook installed to let us interpret the devicename ourselves.
pppd plugin .../pppoe.so PPPoEoptions... eth0
pppd plugin .../pppoatm.so PPPoATMoptions... 0.0.101
> >From the kernel side, My proposal is that whatever interface chosen is,
> it should be able to very easily add new "PPP over X"s; so a registration
> API is a requirement.
No, it isn't. The registration takes place at another level
* tty: registers a new line discipline (register_ldisc)
* PPPoE: registers a new socket family
* PPPoA: registers a new atm "backend" (actually the way you register
a backend in linux-atm is really gross... on my todo list for 2.5
is clean that up)
All the register/unregister stuff (like autoloading) then gets
dealt with at another level.