[openbeosnetteam] Re: Mailing lists and network team questions
- From: "Joseph Liu" <froseph@xxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 16 Mar 2006 21:21:39 -0500
On 3/16/06, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
> Waldemar Kornewald <wkornew@xxxxxxx> wrote:
> > Axel Dörfler wrote:
> > > just a minor observation: since our current networking stack is
> > > already
> > > integrated, and at least somewhat working - would it be more or
> > > less
> > > work to get it work correctly than porting a whole new stack (even
> > > if
> > > that stack would then be better)?
> > The netstack is absolutely not dead-lock free. It would take
> > incredibly
> > much time to get it working reliable. We might try to create a BGL
> > around it, but seriously...we need something better. Also, some
> > features
> > in our netstack don't work (non-blocking socket?).
>
> Well, that's not a long list. And this is a port after all - why do you
> think the next one would be less work than fixing those bugs?
> I mean I don't like what I see whenever I look into our networking
> stack code - but that doesn't mean it's really that bad code - just
> badly written :)
>
> > > Just wondering if it's worth the effort. Also, if we don't intend
> > > to
> > > stick with the FreeBSD stack for R2, it makes the porting effort
> > > less
> > > valuable - plus, if that's the case, it would also doesn't make
> > > much
> > > sense to create BSD like APIs in the kernel, instead, it would be
> > > better to adapt the stack to our kernel.
I was under the impression that the benefits of porting freebsd net
stack was to put it into maintentce mode quickly and then for r2 or
whatever we would hopefully have enough people to write something
which is tailored to the goals of Haiku.Currently we don't have many
developers and it seems that we would be better off boost straping
things off of other projects and replaces those parts as appropreate.
I'd rather get a working stable system up than something which is
fast, but crashes a bunch. OTOH I with BGL around the current netstack
at this point in time. If we don't want to support lots of stuff for
now (just basic implementations of tcp, udp, and ipv4) it might be ok
just to go with our current stack. I havn't looked at it much as i was
under the impression that we wanted to replace it with a BSD stack.
> > I think that LWKT is a very valuable API, in general. We should use
> > it
> > in VFS, drivers, and everywhere possible. Maybe even export it to
> > userland, so we can finally get rid of all those dead-locks in
> > app_server, etc.
> > We need better, more productive, and safer APIs. We should use smart
> > pointers and dead-lock free synchronization where possible.
> > Unfortunately, we're not making use of tools that help writing better
> > code.
> >
> > That's why I think DragonFly is better.
>
> It's not, and lwkts are not - they just have a different objective
> (besides the fact, that right now, DragonFly is certainly better than
> Haiku, alone for the fact that it works :-)).
> As I tried to explain, as long as there is no way to unconditionally
> interrupt a non-interrupt thread by another one, this technique is not
> interesting for a Desktop oriented (responsive) operating system.
If you embrace the lwkt model (data localized cpus or dedicate a cpu
to a task such as tcp), I think the tokenizing aspect is rarely used
(i didn't see any in the dfly netstack). I also don't exactly what you
mean by "you can't unconditonally interrupt a non-interrupt thread".
Even in critical sections, they allow you to interrupt, but instead of
doing work, they schedule it for the end of the critical section. But
regardless of this point I'm not convinced that processor affinity
will lead to a more responsive system. Since the whole idea behind
lwkt is the processor affinity/locking idea, we may as well not use
it.
Cheerio, Joe
Other related posts:
