[openbeosnetteam] Re: Few more things...
- From: "David Reid" <dreid@xxxxxxxxxxxx>
- To: <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Wed, 16 Jan 2002 20:11:18 -0000
> >> Do you mean here that you want a userland network here, like net_server
> >?
> >> What is the general idea about that anyway ? Kernel level, or user
> >level ?
> >> Also, I heard that the people behind the Mail Daemon Replacement wanted
> >to
> >> do a network stack as well. Anybody heard anything on that ?
> >
> >I think in any decent solution it'll be a hybrid, part kernel, part
> >userland. The reason is that if we're wanting to take full advantage of
> >performance we need the "raw" layer to be in the kernel, but the higher
> >layer should really be userland so it can be updated and so on in an
> >easier manner.
>
> 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 if this is completely correct and if it is a good example,
> but look at the App_server. It is completely in userland and uses the
> graphic card drivers to put stuff on the display. Seems to work pretty
> fast.
OK, but that's a single channel, i.e. it's throwing stuff onto the
display...
> 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)
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?
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!
> >I know the guys doing the mail kit and would hope that we can work
> >something out. I really want to see us avoid duplicating effort on this.
>
> I only heard that they wanted to do it, but they now seem to be doing
> different things.
> Nathan on glass elevator. BGA on BFS.
Yes, they do seem a touch involved elsewhere.
> >This should be a definite aim. In fact for ssh/sshd openssl is kind of a
> >given, so maybe we should add it to the list. I'd like to see us
> >distribute a version of openssl with the main os as so many people need
> >it. I know there's a version that runs on bone.
david
Other related posts:
