[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions
- From: "Joseph Liu" <froseph@xxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 16 Mar 2006 02:27:09 -0500
Hey all,
I have read more of the smp code in haiku, and it appears that we
could port lwkt mechanisms on top of haiku. It would be kind of weird
because it appears that we just have 1 scheduler running at any given
time and the free cpu just takes the next thread to be scheduler from
the queue. As such some of the stuff in lwkt doesn't really make sense
in our framework. The whole point of the lwkt api is that all lwkt
have a processor affinity and are only moved every once in a while
sort of like ULE, but more modular. Another point is that due to the
fact that lwkts are "stuck" on the cpus that they are placed on, you
can create data which is local to the cpu, thus freeing up the need
the lock the entire bus except for specific instances.
If we were to port Dragonfly BSD, i think most of the stuff would end
up being translated as mutexes. Some of their lwkt subsystems like
messanging (often used to update data between threads to maintain
consistancy) would be weird hacks as they are messages between cpus
rather than a messages between threads.
Dragonfly bsd would be a little more work of porting another set of
apis and debugging it. If we decide on implementing lwkt in our kernel
or any kind of cpu affinity in the future, dragonfly bsd seems like a
better bet just to get it over with. If we aren't I would guess
probably sticking with plain old freebsd to user their size as a
crutch. As of the current state (i've been pulling fromallbsd.org, so
maybe freebsd 5.x?), freebsd and dragonfly's net stack look similar.
I'd really like other people's input before I start hacking away.
Cheerio,
Joe
Other related posts:
