Hey folks,
Sorry if I've messed up the attribution of things, but I'm replying off of
text copied from a web page since I'm not on the sparclinux-cvs
list. I've added netdev to the cc list since that seems more appropriate
coverage.
jamal sayth:
> On Mon, 31 Jan 2000, Andi Kleen wrote:
> > Sorry for the confusion. There seems to be some inflation of PPPoE
> > clients on linux at the moment (The Spellcaster guys apparently
> > released another one with their PPP code, there are various user space
> > versions floating around etc.)
> The spellcaster one requires a replacement of the PPP stack in the
> kernel as well.
This is a good thing! =) I wrote that pppoe code as a quick hack one
night after looking at the userspace implementations... It does the
discovery in userspace, then does a 'dial' with the target MAC address and
session id. That PPP stack is the way it is mostly because it wasn't
being merged at the time it was being developed, so it couldn't patch
anything else in the kernel and it had to run across 2.0/2.2/2.3. If I
were to do any work on it now, I'd make it use a PPP socket instead of the
charater device. The biggest benefit of the code is that it handles all
PPP connections in a single daemon, so it requires a lot less from a
system than using pppd. The multilink code is also well abused, and
performs well against just about everything out there if the underlying
device gives sufficient back pressure on transmit.
Suffice it to say that I wouldn't expect to see the Babylon code merged as
is, but there are useful bits and ideas in it.
> > The problem with jamal's 2.3 code is that it doesn't use the ppp
> > channel support in 2.3 yet, it still runs over a line discipline with
> > the tty PPP like the 2.2 version. I think porting it to ppp channel
> > would be straight forward and jamal planned this anyways very soon.
> It is straight forward. I have been hesitant doing so because i am
> trying to be a minimalist. I have asked Paul Mackerras (Cced in this
> mail) if i could make some small changes to remove what i think is a
> small limitation to the Channel stuff and make it more generic. This way
> we dont have to modify it for PPP over UDP(L2TP), PPP over ATM
> etc. Paul will hopefully give me the green light. My secondary goal is
> to get speed. And so if it turns the current tty design is faster than
> the channel mode, then i'd rather stick to the tty mode.
I'll just say that the tty subsystem sucks. You haven't tried writing a
driver for a DMA driven board with an ARM processor driving the DSPs that
does all of the PPP framing for you, but can also be a tty (yet it still
likes getting its data in chunks) -- flip buffers are a pain. The tty
code gets in your way big time, and sucks alot of performance out of the
system.
-ben (who's also of the opinion that most of the i4l
stack should be in user space, especially that
evil modem emulator)
|