[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions

  • From: "Fredrik Holmqvist" <fredrik.holmqvist@xxxxxxxxx>
  • To: openbeosnetteam@xxxxxxxxxxxxx
  • Date: Thu, 16 Mar 2006 08:51:31 +0100

Hi, I've been following the list a while and some may know me from Firefox /
Mozilla for BeOS. I'm not 'good' at network-programming, but the topic
interests me. Joseph, I must say you are doing a very good job at explaining
the difference of the stacks.

My thougths:
* A port of lwkt should probably be discussed with the kernel-team. With
proper support in the kernel it might be very nice.
* Could we replace the use of lwkt with calls to current API completly or is
lwkt used everywhere in the stack?
* Is it possible to go from FreeBSD to DragonFly later without to much pain
if we were to start with a straight FreeBSD-port?

Also on more practical things:
Wasn't there a specific branch in the Haiku SVN where a new network-stack
was checked in? Should we set up some branch with the stack (of our choice)
so we can start hacking on it.

/Fredrik Holmqvist, TQH


On 3/16/06, Joseph Liu <froseph@xxxxxxxxx> wrote:
>
> 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
>
>


--
Fredrik Holmqvist
Chaordic: things that thrive on the edge of chaos with just enough order to
give them pattern, but not so much to slow their adaptation and learning.

Other related posts: