[openbeosnetteam] Re: [openbeos] Re: Mailing lists and network team questions
- From: "Joseph Liu" <froseph@xxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Wed, 15 Mar 2006 13:08:47 -0500
On 3/15/06, Philippe Houdoin <philippe.houdoin@xxxxxxx> wrote:
> Quoting Joseph Liu <froseph@xxxxxxxxx>:
>
> > Hi,
> > I have been thinking about helping out with the network stack for a
> > while, and this weekend I finally got a chance to look at some code.
>
> ... and your still wanting to help us?
> Woa. I'm impressed.
> We need you!
> ;-)
>
> > > This is a quick TODO list:
> > > * analyze if we can get DragonFly's netstack ported (easly!)
> >
> > If we have a threading model like DragonFly's it would be easier,
>
> Beos/Haiku offer a "lightweight threading model" like *but* not compatible
> with
> DragonFly's lwkt. And as for I know, under BeOS/Haiku the threading model is
> the same for both kernel and userland (space switches aside).
> But I don't know much more about lwkt than any osnews.com lurkers could :-\
>
> > otherwise it we would have to port essentially all of to lwkt api to
> > our equivilent representation. Dragonfly has only made some sections
> > of the network stack parallel, and added some serialization.
>
> Oh. So that's not much more threaded than the current FreeBSD stack, then?
>
> > If we arn't using their threading model, it might be better to follow
> > FreeBSD net stack, but the simplicity of the DragonFly lwkt is really
> > nice :).
>
> Could you tell us more about lwtk?
> Some sample code to show its easy/better to use?
> Maybe it could help us to estimate if a quick wrapper emulating lwkt under
> BeOS/Haiku could be written. Or not.
From what I grather reading
http://www.dragonflybsd.org/goals/threads.cgi and the lwkt api,
LWKTs are the kernel land threads which can be kernel threads or
mapped to coresponding user threads. The user land scheduler lies on
top of the lwkt scheduler hence you can switch schedulers when you
want. The key idea is that each CPU has its own lwkt scheduler and
each lwkt are thus locked to a specific processor unless there is an
IPI to move it to another processor. (i should look into how, if ever
they do that). Hence it is easier to understand and there is no need
to do lots of locking stuff unless you need to do some syncronization
between processors. They use critical areas to prevent interrupts from
the same cpu. If an interrupt occurs on the same cpu while in a
critical area, the interrupt handler is placed in a lwkt, cricial
section finish executing, and then the interupt handler is run.
Compare this with a kernel with a GIANT lock (kernel areas can only be
run on one cpu at a time) or fine grained locks (crictical sections
protected by locking mechanisms). It just seems harder to keep track
of everything where as lwkts can essentially think of themselevs as
running on the same cpu. As such i'm not sure how easy it would be to
port the lwkt api over to our model which appears to be a more
traditional bsd like model.
For example when sending on a socket, FreeBSD locks on sending of a
particular socket where as Dragonfly essentially locks on the device
to serialize output to the device.
If we want to investigate more into their threading model, I can
investigate more. I only looked at lwkts in the context of the network
stack.
>
> > I still need to read more Haiku code, but it we need to have
> > uio, mbufs, sockets and all the stuff which makes up the transport and
> > network layers. Any one have any thoughts/opinions?
>
> The current stack code have already many of these beasts under
> src/add-ons/kernel/network/core/*, so it's not a port stopper. Not that I'm
> used to all these BSD networkishes that much myself...
> I never understand what uio was really about, btw. Do you know?
I was under the impression we wanted to scrap our current kernelland
implementation, dump in what BSD has and the hack at the glue layers
to make it compatible with what we have. This would make it easier to
maintain the port. UIO - universial io. From
http://www.freebsd.org/cgi/man.cgi?query=uio&sektion=9 it's an io api
which device drivers implement.
Other related posts:
