> 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
Which interface are you referring to? Netlink sockets or "/dev/ppp"
or something else entirely? I'm a bit confused...
> 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.
Adding in more hooks to support plugins would appear to be the way to
go. As implied in Mitchell's thread we'd want a device name
recognition hook as well as "connect" and "disconnect" hooks.
Extending the functionality of plugins, and perhaps isolating the tty
code into a default plugin would give us the functionality and
flexibility we want.
> 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).
As Mitch pointed out most of what I mentioned is already there with
plugins, though we need to add more hooks. It appears that the
"channelname" semantics you propose are equivalent to plugins with
support for a device name recognition hook.
Quite frankly I think it's pretty nifty to be able to do "pppd eth0".