[openbeosnetteam] Re: Few more things...

> >> 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.

Well, you can have really great stability and crap performance, personally
like I like a good mix :)

Basically, on both BONE, net_server, FreeBSD, OpenBSD if you push the
network stack in a really hard, aggressive manner you can normally
eventually cause things to go wrong.  If you're running at high load it'll
go wrong and you'll need to reboot.  Trust me, I've had very impressive
loads running through BONE and resulted in it crashing through some stupid
code in apache that I'd written :(  Basically, nothing is ever guarenteed!
This is where we get to play, in that we (as the developers) will be
expected to push and find the boundaries, expand them and then push some
more.  That's why it's so much fun!

> >> 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...

OK.

>
> >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.

This piece from the newos web site is what I was afraid of when I saw we
were basing on newos...

"Developers that wish to join in should take a look at the code and see
where you want to help out and drop me a mail and we'll see where we can
work together. I'm pretty interested in keeping the core kernel design for
myself, but drivers and user space libraries and even higher level stuff is
pretty negotiatable. A few people have already helped me with drivers and
I'm very grateful for that."

"core kernel design for myself" :(

david

Other related posts: