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.