On Thu, 3 Feb 2000, Mitchell Blank Jr wrote:
> jamal wrote:
>
mitch >I really don't see why the channels stuff in 2.3 shouldn't just
mitch >stay as is - it's really very clean. The real work that needs
mitch >to be done is to pppd to support plugins that deal with different
mitch >channel types better.
mitch >
Nobody is suggesting to touch the generic stuff
mitch >
mitch >...PPTP, ISDN-PPP (is that using the new ppp_generic code yet?),
mitch >RFC 1598 (PPP-over-X25), RFC 1973 (PPP-over-Frame), RFC2363
mitch >(PPP-over-FUNI-ATM)...
mitch >
You made my point.
mitch >> The problem IMO:
mitch >>
mitch >> Too many solutions; same end goal --> kernel cluttering.
mitch >
mitch >The problem as I see it is just that more things need to
mitch >convert to the channels stuff (ppp_generic and friends)
Nobody is arguing about that. In 2.2 it is out of question. tty
is the only answer.
mitch >> -No changes required for any PPP/d (user/kernel)
mitch >
mitch >I don't see this an advantage - recent pppd's have a plugin
mitch > mechanism
mitch >which could make these changes very clean (see the PLUGINS
mitch >file in a recent pppd). All that is really needed is the
mitch > tty-specific
mitch >stuff in pppd to have hooks put around it so it can be supplanted
mitch >easily by non-tty variants. Then each PPP-o-X can just have
mitch >its own module.
I am in agreement.
mitch >
mitch >The only challenge is getting a firm enough grasp on all the
mitch >pppd code that deals with ttys so the small surgical changes
mitch >can be made without upsetting other ports. I haven't had
mitch >time to divine this level of understanding of all those
mitch >twisty little passages.
nod.
mitch >
mitch >> Code size in the kernel (At the moment about 60k)
mitch >> This includes also the server part.
mitch >> Contribution from the socket addition: about 30% of this
mitch >
mitch >I think this is fine. PPPoE is a full-fledged protocol with all
mitch >the mux/demux needs that implies. It's just going to be a
mitch >little large if you want a flexible implementation. None of
mitch >that has anything to do with the choice of ppp implementation.
Did you really read the whole thing before posting ;->?
Nobody is saying anything about touching the ppp implementation;->
And just because some protocol needs a mux/demux interface does
not equate it to sockets; have you thought of using netfilter
modules? And why not, since they can provide you with nice mux/demux
interface?
mitch >
mitch >Look at the ppp-o-atm code - since the VCC mux/demux is handled
mitch >by the higher layer (it's just over a standard PPP socket)
mitch >the code to use the ppp_generic channel interface is almost
mitch >trivial. If I had to rewrite it to emulate a tty interface
mitch >not only would the performance suck eggs, but the code would
mitch >be much larger.
mitch >
For PPP over ATM it might actually make sense to do the VCC mux/demux
socket(AF_ATMPVC, SOCK_DGRAM, 0) as you do because you already have the
VCC being mapped to the socket by design. i.e you did not create the
AF_ATMPVC just so that you can do PPP over it unless i am totaly
misunderstading the reasoning behind the AAL5 semantics.
mitch >> Advantages:
mitch >> does not use the tty interface. Uses the channel interface;
mitch >>
mitch >> Disadvantage:
mitch >> -Bloats the kernel.
mitch >
mitch >Again, wrong. For a simple to implement protocol it bloats
mitch >the kernel less than ppp_async does.
mitch >
I dont think so. But thats a moot point. The point is:
Add stuff in the kernel only when it will make sense for more
people to use it; If you can do it in user space -- do it there!
If you can improve performance by moving pieces into the kernel,
then that is a good justification.
mitch >> -The socket use could become a maintainance nightmare
mitch >> (claim: it looks very clean at the moment).
mitch >
mitch >It's not a maintence nightmare. Quite the opposite - using
mitch >a socket family gives you all the socket infastructure (like
mitch >module auto-load) for free.
mitch >
So iam saying that because it is a lot of code.
You might have a point -- i still havent seen it.
mitch >> -Creating a whole socket family for just PPPOE is a bad idea
mitch >
mitch >I don't think so - it has its own addressing, so it needs
mitch >its own address family.
mitch >
Bad reason.
mitch >Why make a new pppoxd? Wouldn't it be easier to just use a pppd
mitch > plugin?
mitch >
I think thats what we are saying. I.e just another plugin or a thing
that talks to pppd.
mitch >
mitch >>
mitch >> We are all curently in violent agreement that discovery should be
mitch > in
mitch >> user space (includes Michal).
mitch >
mitch >Then I'll be the violent dissenter, I guess. I don't think
mitch> discovery
mitch >is analagous to ARP (which also has a right to be in the kernel,
IMO)..
mitch >it's more analagous to TCP connect.
So why dont you move OSPF to the kernel? It has its own addressing,
it does its own demuxing/muxing etc..
mitch >> The main decision to make is what interface should PPPd be
mitch >> talking to? For 2.2, the only viable solution is the tty one.
mitch >
mitch >I think we should just write off 2.2 - 2.4 is on the way.
mitch >If someone wants all these PPP-o-X things in 2.2 that badly
mitch >then they should do a back-port of ppp_generic and friends.
You can use the generic tty interface i provided for 2.2.
mitch >
mitch >> So what should be the device that pppd talks to? Is it a new
socket
mitch >> family, tty device, a new char device etc.?
mitch >
mitch >Depends on the "X" in PPP-o-X!
mitch >
mitch > tty: can talk to a tty device just like now
mitch > PPPoE: new socket family
mitch > PPPoA: ATM_PVC socket
And what about PPP-over-Frame, PPP over UDP ;->
Create a new socket family for each?
mitch >etc
mitch >
mitch >I think this can all be handled by the plugin architecture. We
just
mitch >need a hook installed to let us interpret the devicename ourselves.
mitch >
mitch > pppd plugin .../pppoe.so PPPoEoptions... eth0
mitch > pppd plugin .../pppoatm.so PPPoATMoptions... 0.0.101
mitch >
You need to have both a connect and disconnect; It could be via plugins
or the already provided features of "connect" or "disconnect"
mitch >No, it isn't. The registration takes place at another level
mitch > * tty: registers a new line discipline (register_ldisc)
mitch > * PPPoE: registers a new socket family
mitch > * PPPoA: registers a new atm "backend" (actually the way you
register
mitch > a backend in linux-atm is really gross... on my todo list for
2.5
mitch > is clean that up)
mitch >
mitch >All the register/unregister stuff (like autoloading) then gets
mitch >dealt with at another level.
mitch >
I didnt quiet follow -- but i'd like to understand what you are saying.
cheers,
jamal
|