[Top] [All Lists]

Re: RFC: PPP over X

To: paulus@xxxxxxxxxxxxx
Subject: Re: RFC: PPP over X
From: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Date: Wed, 16 Feb 2000 06:18:53 -0800
Cc: jamal <hadi@xxxxxxxxxx>, netdev@xxxxxxxxxxx, axboe@xxxxxxx, Mark Spencer <markster@xxxxxxxxx>, Andi Kleen <ak@xxxxxxx>, Marc Boucher <marc@xxxxxxx>, Henner Eisen <eis@xxxxxxxxxxxxx>, Michal Ostrowski <mostrows@xxxxxxxxxxxxxxxxx>, Ben LaHaise <bcrl@xxxxxxxxxx>
In-reply-to: <20000207143007.O31166@xxxxxxxxxx>; from mitch on Mon, Feb 07, 2000 at 02:30:07PM -0800
References: <Pine.GSO.4.20.0002021030520.22723-100000@xxxxxxxxxxxxxxxx> <20000203120127.J72648@xxxxxxxxxx> <ouemao6eqh.fsf@xxxxxxxxxxxxx> <20000207143007.O31166@xxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Mitchell Blank Jr wrote:
> BTW, sorry I didn't get around to posting patches to pppd yesterday.
> Every time I thought I nailed the "last thing" in pppd a couple more would
> pop up.  I think I'm nearing the end of the tunnel though, so stay
> tuned.

Sorry for taking so long to deliver my promised pppd patches, but
at long last here they are.  These aren't tested (since I have no
PPP line right now to test them with :-), so if interested parties
could give them a whirl and make sure that I haven't broken too
many things, I'd appreciate it.

This patch to pppd-2.3.11 makes it possible to implement non-tty
backends (PPPoATM, PPPoE, etc, etc) using the existing pppd plugin
mechanism.  Specifically...

First, I changed plugin_init so that they are loaded (and plugin_init
called) during option-pre-parsing time.  This was a bug in the past -
before plugin's add_option's weren't processed until later option parsing,
which meant that plugin-added options and their arguments could get
confused with speeds and device names.  This change also means that
plugins can have deeper impacts on the parsing process.  I also added
an (optional) plugin entry point "plugin_init_later" which is called
at the time that plugin_init used to be called in case any future plugins
need that (for instance if they do something at init-time that requires
that "devnam" has been determined)

Second, I added twelve new hooks which can be used to override most
all of the tty-specific behavior in the default pppd.  This provides
enough control to implement things like PPPoATM and PPPoE as plugins.
These additional hooks are documented in the PLUGINS file (I also
took the liberty of documenting the ip_{up,down}_hook hooks which
weren't mentioned there.

I'm also including an example PPPoATM plugin.  *NOTE*: this is for a
new version of the in-kernel PPPoATM driver which I am working on,
not the one that Jens Axboe is distributing (which in turn is based
on my original version).  Therefore this plugin will neither compile
nor work, but is only meant as an example showing how a non-async
discipline would be implemented using the new hooks.

One aspect of pppd which does NOT work with non-tty backends is
demand dialing - the current implementation is heavily reliant
on substituting a pseudo-tty for the real device and that just
won't work for a non-tty device.  Paul - can demand-dialing be
redesigned?  I think it would be easiest if the kernel considered
"waiting to dial" as another ppp_channel which just queues skb's
and notifies userland somehow.  That way you could demand-dial
PPPoATM or PPPoE using the same mechanism for ppp_async.

I hope that these patches look good.. Paul, if you don't like anything
let me know.  I'm going back to working on the PPPoATM kernel-side now.


Attachment: pppd-2.3.11mnb1.patch
Description: Text document

Attachment: pppoatm.c
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>