FreeLists / openbeosnetteam / [openbeosnetteam] Re: Few more things...

[Mark Hellegers <M.H.Hellegers@xxxxxxxxxxx>]

>> You'll have to be a bit more specific about that. What I think should
>be
>> in the kernel are part of the drivers. The rest should be able to go in
>> userland. Userland has the advantage that if it crashes, it won't take
>the
>> whole OS with it.
>
>Yeah, yeah, yeah, heard that argument before.  Trust me, you abuse the
>network stack (and I have done a few times :)) it's a reboot, even on
>R5.1 :(

I don't know what you're talking about here as I don't have R5.1. Do you
mean abusing the net_server or BONE ? Sorry if I'm beating this thing to
death, but I'm after stability, speed is second to me. If net_server can
cause you to reboot after abusing it, there is something wrong.

>> Just keep in mind that while I know how to do some network programming
>on
>> the socket level, I don't know anything of the level below it. If this
>> disqualifies me from the discussion, just ignore me. :)
>
>Some examples, how would you handle a select call that has fd's, pipes
>and sockets in userland?  You have suddenly got a lot of cross
>dependancy.  My view (and this is the first time I've tried to write it
>down, so bear with me) is that we have roughly the following (none of
>this is set in stone)

You're losing me with the select call, but anyway...

>i/o from the cards is controlled in the kernel.  A card has data
>available, the kernel looks at it and matches to the socket etc etc.  At
>the lowest level the socket is just a simple gateway onto an interface,
>internal (loopback) or external (a network card, modem). Exactly how that
>socket is actually driven (is it IPv4, v6, UDP) is actually down to a
>higher level of library, the protocols.  However, the job of getting data
>to/from the inteface is the job of the kernel/drivers, and I think the
>code that needs to go in the kernel is the controls for that movement.
>Also there should be select/poll and possibly some of the other very low
>level stuff, like buffer space and so on.  This is what feels right to
>me, but may not be possible.
>
>I'm not talking about moving the whole of the networking into the kernel,
>just the portions where performance and integration are truly vital and
>they have a potentially wider audience.  Does that make more sense?

Let me see if I can follow you here. You want to put the socket stuff on
the kernel level ?
Is that something like to the read and write calls for drivers, but a bit
more geared to what network stuff need or is it a little bit higher ? What
do you mean by "may not be possible" ?
I don't have any objections to that kind of kernel level stuff. Small
pieces of code are easier to make stable.

>There is also a counter argument that says that drivers could be user
>space, so go figure :) For as many developers we have a lot of
>viewpoints!

If you want user space drivers, I think QNX has that. :)

Mark