public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Mcadams <jeffm@iglou.com>
To: Paul Mackerras <paulus@samba.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SyncPPP Generic PPP merge
Date: Fri, 25 May 2001 12:44:35 -0400	[thread overview]
Message-ID: <20010525124435.A24448@iglou.com> (raw)
In-Reply-To: <002501c0e48f$ffed1e40$0c00a8c0@diemos> <E1533Ra-0005hC-00@the-village.bc.nu> <20010524185333.B7667@iglou.com> <15117.44426.899390.29151@tango.paulus.ozlabs.org>
In-Reply-To: <15117.44426.899390.29151@tango.paulus.ozlabs.org>; from paulus@samba.org on Fri, May 25, 2001 at 10:55:38AM +1000

Also sprach Paul Mackerras
>Jeff Mcadams writes:
>> Indeed.  And let me just throw out another thought.  A clean
>> abstraction of the various portions of the PPP functionality is
>> beneficial in other ways.  My personal pet project being to add L2TP
>> support to the kernel eventually.  A good abstraction of the framing
>> capabilities and basic PPP processing would be rather useful in that
>> project.

>That is exactly what ppp_generic.c is intended to do - it abstracts out
>the framing and encapsulation and low-level transport of PPP frames
>into ppp "channels" (see for example ppp_async.c, ppp_synctty.c) while
>ppp_generic.c does the basic PPP processing (compression, multilink,
>handling the network interface device etc.).

>You should be able to write an L2TP channel to work with ppp_generic -
>all your code would need to know about is how to take a PPP frame and
>encapsulate and send it, and how to receive and decapsulate PPP frames.

>[Note to myself: send in a Documentation/ppp_generic.txt which
>describes the interface between ppp_generic.c and the channels.]

That's all well and good...and useful...and I'll probably take advantage
of it...but I think you missed my point (although I have no doubt that
my point was not at all clear!)

L2TP potentially has to convert a PPP frame that is given to it to or
from async or sync framing.  ppp_async.c has a ppp_async_encode()
function that would be useful to me in L2TP...it'd kinda suck to have to
duplicate that functionality.  Although it looks like the corresponding
decoding funcationality is tied up in ppp_async_input() which kinda
sucks a bit as well.

Anyway...the idea being that it would be nice to be able to have easy
access to some of the functionality that's part of the channels
currently, but could conceivably be abstracted out even further.

The question, I guess, then becomes whether its worth it to do this
extra layer of abstraction and adding another layer of interaction
between modules for the benefit that it provides.  I certainly wouldn't
squabble if the general concensus was that it wasn't worth it.  :)

Oh, and before anyone points this out, yes, L2TP changing the framing of
the PPP frame above is definitely a violation of layering...if you'd
like, I can point out plenty of other places where L2TP violates
layering principles.  :)

>> I would agree that such a project would be 2.5 material.

>Do it today if you like, I can't see that adding a new PPP channel
>could break anything else, it would be like adding a new driver.

Well...L2TP support is 2.5 material as far as I'm concerned because I'm
not much of a programmer in general, and have never done any kernel
programming...so I'm still getting up to speed on things, and it'll
probably take me until fairly well into 2.5 to even really consider
unleashing a kernel-level creation of my own onto the world.  :)
-- 
Jeff McAdams                            Email: jeffm@iglou.com
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

  reply	other threads:[~2001-05-25 16:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-22 10:51 SyncPPP IPCP/LCP loop problem and patch rjd
2001-05-22 12:31 ` Paul Mackerras
2001-05-22 13:34   ` rjd
2001-05-22 16:11     ` Paul Fulghum
2001-05-24 15:11       ` SyncPPP IPCP/LCP loop problem and patch. Take 2 rjd
2001-05-22 18:13     ` SyncPPP IPCP/LCP loop problem and patch Paul Fulghum
2001-05-24 15:30       ` rjd
2001-05-24 16:56         ` Paul Fulghum
2001-05-24 18:13           ` Alan Cox
2001-05-24 20:27             ` SyncPPP Generic PPP merge Paul Fulghum
2001-05-24 22:18               ` Alan Cox
2001-05-24 22:53                 ` Jeff Mcadams
2001-05-25  0:55                   ` Paul Mackerras
2001-05-25 16:44                     ` Jeff Mcadams [this message]
2001-05-24 23:27                 ` Paul Fulghum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010525124435.A24448@iglou.com \
    --to=jeffm@iglou.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox