FreeLists / openbeosnetteam / [openbeosnetteam] Re: PPP, libnet, and why inside the kernel?

["David Reid" <dreid@xxxxxxxxxxxx>]

> > When the kernel couldn't load the networking stack module,
> > the call to socket() could just return an error, it doesn't
> > have to be included in the kernel for this.
>
> It's exactly what it does *already* if, for whatever reason, the
> stack can't be accessed.
>
> > Anyway, I would rather see *all* networking related functions in
> > libnet.so.
>
> And most if not all R5 apps will *look* in this same library, too.
> It's not like we've really any choice, here.
>
> But I think what David have in mind on this topic is
> bypassing the /dev/net/stack driver, by exporting the today
> core's soinit + socreate in a kernel socket() syscall, which the userland
> part socket() will simply call from libnet.so. And same for all others
> sockets API.
>
> My opinion on this suggestion is I would like better a kernel
> who don't even know what a network stack or socket is. He knows
> only what file descriptors are, and that's far enough we needs.
> Small is beautifull.
>
> Let's hide any network stuff to the kernel by placing them
> in kernel modules, that the purpose of a modular kernel: we can expand,
> dynamicly :-) what's the OS low-level services...

Once again I go away anf you all spend time jabbering about stuff that I've
told you before!

Anyway, just to reiterate for the cheap seats or those with white sticks and
dogs...

There will be a degree of network functionality going into the kernel. IMHO
that's where it belongs due to the hooks it needs to be truly efficient.
The /dev/net/stack will be going away when we move to kernel land proper. As
for not knowing anything about sockets, what is a socket from the kernel
pov? It's just another "window" into the kernel in the same way that calling
open on a file is. Upgrading socket really isn't a concern, nor most of the
other stuff that will end up in kernel. Look at the dates on some of the
files and you'll find the main "non patch" changes were made in the
early-mid 90's for most of them.

There will also be kernel modules for everything else. Where the line gets
drawn is still open to some debate.

Nathan: As I'm getting tired of typing - PPC isn't an essential or even
desired piece of OpenBeOS R1, so support isn't there. Sad but true and not
something I am really in a rush to change. As for not opening a lot of
sockets, try opening BeBits using Net+. It opens a lot of sockets in very
quick succession (like 20+) and the writes/selects/reads from them. I've
also said if you want to work on the project then there is a lot you can do
without needing physical access to a machine, but as you don't want to do
this...

Just to repeat something that hasn't come up for a while, this project is to
get a the best stack we can for OpenBeOS using the new kernel. If we can add
support for R5 then fine, but it's not even on my list of priorities. The
reason it's been so debated is that I've been using R5 as my development
platform - nothing else.

Philippe, best of luck with select and if you get it working I'll be glad to
see it in CVS.

david