lkml.org 
[lkml]   [2001]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SyncPPP Generic PPP merge
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.069 / U:3.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site