[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions
- From: Waldemar Kornewald <wkornew@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Fri, 17 Mar 2006 11:19:30 +0100
Axel Dörfler wrote:
Actually, locking really isn't that hard in most situations. If you
need to prevent deadlocks this way, I would recommend to redesign your
locking.
I went too far with my attempt at parallelizing everything. My plan is
to make it less concurrent (only useful for multi-link interfaces,
anyway) and try to remove as much locking as possible. But I want to
take on the website task, at first.
Unfortunately, in complex software locking becomes "pure hell". Look at
app_server.
The fact that lwkt a) can't interrupt threads unconditionally while
having a token, and b) that it locks them to a single CPU is both not a
good solution. It doesn't allow for for short latency thread scheduling
for one - only for interrupts. IOW they should only be used for very
short critical zones - then they actually have an advantage over
disabling interrupts and acquiring a spinlock.
I agree that under certain circumstances latency could be a big problem
(e.g.: waiting for data from a device), but how often do you have huge
transactions and how often is it impossible to split that into multiple
concurrent (and asynchronous) transactions? In many cases we can work
around the problem by sending messages. Also, Joseph already said that
DragonFly's netstack rarely uses tokens, at all (probably because of
CPU-affinity).
Semaphores often force us to create huge locked sections (or we're too
lazy to implement fine-grained locking), but this does not at all mean
that we should use the same development scheme for alternative
implementations.
Maybe we can design something that does not have latency problems (or we
can still consider STM)...that must be discussed for R2, at least.
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 :)
Let's make the list a little bit longer. :)
* not dead-lock free
* unstable (also: old, unfixed bugs)
* security issues!!! (old, unfixed vulnerabilities)
* hacky, ugly, difficult to understand
* non-blocking sockets don't work
* functionality got lost (e.g.: routing), often because of modularity
* hard to interface with netstack
* even DHCP is missing! :(
For R1.x we will also want to have:
* WiFi
* IPv6
* IPsec
* VPN
* WiMAX
* Bluetooth
* ...
If we start fixing our current netstack then we are only delaying a port
of <x>BSD for a few months (if at all). That is wasted time.
Joseph Liu wrote:
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 doubt that we will *ever* have time to work on our own netstack. As I
always try to make clear, we have *so* many userland networking tasks
that writing our own netstack would always get _lowest_ priority. Just
think about how much time it would take to get a new protocol like WiMAX
added into our netstack. Even a straight port from FreeBSD would require
maintenance work (adapt their changes to our netstack...).
Modifications: yes.
Big rewrites or conceptual changes: I doubt it. But if we can come up
with a cool solution to the concurrency and productivity issues that
makes the netstack significantly easier to understand and develop for
then it might be worth a rewrite.
So, since LWKT and CPU-affinity are not acceptable let's simply port
FreeBSD. That should be much easier, anyway.
Bye,
Waldemar
Other related posts:
