Good to see this discussion is happening./
michal>I take it that you meant to apply your "channelname" proposal to
michal> This would mean that pppoxd is some module inside pppd that does
michal>I think that for PPPoE at least sockets (of some form) are the way
michal>to go, because with a sockets approach we have code that maintains
michal>consistent semantics. What that means is that the code looks like
michal>network code all the way through (with no need to translate to tty
michal>semantics and vice-versa), and that's why I think it is a very
michal>"clean" solution (from a high-level perspective). Although this
michal>probably requires more code (infrastructure code to support a
michal> socketsinterface) it's as efficient as anything else on a
michal> per-packet basis (using PPP-channels).
No the "network-like" skb code is provided by the channel interface.
If you use the channel interface, you get skbs. I ma not totaly against
using sockets, but you need a more convincing arguement
(eg look at the netlink interface; it is a char device and yet it
is used in networking abstraction)
Try to be more convincing; if you say that the socket domain will be
something like "pppox" and the type "pppoe" then it becomes a little more
michal>I totally agree with this in general. I have a few concerns about
michal>some of the semantics though: I think that the "channelname" option
michal>should register a back-end channel module. This module would then
michal>provide a function which would try to interpret the "devicename"
michal>option. pppd would try the "devicename" recognizers for all
michal>registered channel modules --- the one that accepts is the channel
michal>that is used. By default a "tty" module is used; this module
michal>encapsulates existing tty control functionality. The reason for
michal> this is that you can then specify "channelname pppoe", and this
michal> works PPPoE connections over eth0, eth1, etc. (the exact device
michal> being specified by the "devicename" options).
pppd currently has "connect" and "disconnect" features. You can attach
scripts to it or even executables. So this is the backend you might be
refering to? This way pppd doesnt have to know anything about the
PPPoX semantics. You are right, we might need to have to pass something
like a channelnumber; so maybe extend the syntax to be something along the
lines "channel <chanelname> <channelid>" eg "channel l2tp 0" in
the ppp passed to pppd in its options.
michal>Perhaps each channel module would provide it's own methods for
michal>"connect"/"disconnect". The "connect"/"disconnect" options as they
This is there today (as mentioned above).
but maybe we need a connect_plugin if you think the current "connect"
is not good enough. 2.3.11 has a neat plugins feature (which seems
a little limited) but allows you to extend the functionality of pppd.
michal>This does raise the issue of how options are treated wrt
michal> modules; we
michal>could allow modules to register their own option namespace (e.g.:
michal>allow for channel specific options such as "pppoe.ac_name").
michal>Thus we would allow for each channel module to register an options
michal>namespace and functions for connect, disconnect, and "devicename"
michal>recognition. With such an approach you could have one options file
michal>which would support PPPoE, tty and xxxx sessions simultaneously.
This sounds like a lot of work to me, no? Why not just have the passing
of the "channel" syntax to mean that this is not a tty?
And then you can add whatever options you want (and maybe ignore most that
dont affect you).