
|
[openbeosnetteam]
||
[Date Prev]
[05-2002 Date Index]
[Date Next]
||
[Thread Prev]
[05-2002 Thread Index]
[Thread Next]
[openbeosnetteam] Re: PPP, libnet, and why inside the kernel?
- From: "David Reid" <dreid@xxxxxxxxxxxx>
- To: <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Sat, 4 May 2002 20:57:27 +0100
Hey, this is open source...talk is very cheap and gets you nothing, code
gets you anything you're going to get.
> > libnet
> >
> > Our present focus has been to get libnet working, and we've been
> > successful
> > in that it now works quite well. We have a lot of the functions we
> > need and
> > a lot more besides, which is very cool. Someone needs to go through
> > and
> > check to see that we have all the functions that libnet.so provided
> > and add
> > missing ones. Again, a volunteer would be really appreciated.
>
> As I said, I'm volunteering for this, starting next week.
We're waiting with baited breath...
> > New kernel
> > 3. Next we start to move into the kernel proper. This will only
> > affect the
> > core (net_server directory) as the individual modules will still be
> > separate
> > and loaded at run time. It's at this point that some functions will
> > hopefully move from libnet to libroot. Now, I don't think this will
> > cause
> > any binary compat issues as libroot and libnet are both loaded by
> > apps under
> > R5, but will start to provide a better platform to move forward with.
> > However, I may be wrong about this :)
>
> What besides select()? I hope things like socket() stay in libnet; that
> is an appropriate place for them. I still don't see what advantage
> there is to being copmiled into the kernel.
Oh come on get a grip. libnet is a userland lib. Things like socket belong
in kernel. Why? What does socket do? It opens a window into the kernel and
the i/o routines that live there. Instead of calling
socket
open
ioctl
in kernel we simply call
socket
No, I can't see any advantage to that at all...
Think about things like accept - again we open a new "window" into the
kernel so of course there's a big advantage to having accept simply make the
required kernel calls and get a new one, instead of doing all the stuff we
do in libnet to get round this problem.
> > PPP
> >
> > We can't put this off forever and so sooner or later we're going to
> > have to
> > start looking at adding this :) Suggestions are welcome as to the
> > "architecture" to use and documents to refer to. I'd like to think
> > we'd aim
> > for ppp, pppoe and pppoa. For the latter we'd need an atm module,
> > which
> > might also be used by network cards, and that may affect the thoughts
> > on
> > architecture?
>
> I would be more than happy to do this. I even have a PPPoA stack for
> net_server (wheeee!), and a significant portion of an old attempt at
> replacing the net_server's PPP stack. I would like to have a ppp_lib.a
> kind of thing that would be compiled into all flavors. Serial PPP would
> be a device in its own right; the others protocol addons.
Well, like I say, code talks. Why the hell do you want a static lib though?
What's the point? I mean have you even looked at how the current
architecture hold together? I think the correct way is
one module that opens the serial port and does the talking... (serial if you
will)
one module that does the interpretation (takes raw and moves it into ppp or
slip talk)
This then passes us into the stack... Not too hard to do and nicely
moularised. If we want pppoa then we have an atm layer prior to the stack...
Really don't see the point of anything beyond this. I'm also thinking that
we should have modules for the various flavours of encryption and
interrogation, i.e. a chap module that knows how to talk chap. When we enter
a negotiation phase we move the handler for input to go directly to this
module and the reset it back to the stack at completion. We have the hooks,
let's use them.
> > Anyway, enough spouting from me. Please let's discuss the contents,
> > but try
> > to reply with a subject line more appropriate and don't just reply to
> > the
> > entire mail in one go as it covers too much ground for that. Be
> > interesting
> > to see who read this bit won't it?
>
> Heh, I only responded to half of it in one go...
> -Nathan
And I replied to it.
I was sure someone would and would've laid odds it'd have been you :) Guess
I should pay myself some money!
david
|

|