Quoting Waldemar Kornewald: > > 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) Agreed. > * hacky, ugly, difficult to understand I guess many used to BeOS/Haiku code will still find even the latest, reworked FreeBSD net stack code the same. > * non-blocking sockets don't work Huh? I though we fixed this issue long time ago. > * functionality got lost (e.g.: routing), often because of modularity > * hard to interface with netstack But this interface is up to us to improve. We're free to do what we want here. The /dev/net/stack main entry will stay, even with a monolithic freesbd netstack working behind it. And we have to introduce more live updates to support userland features, like ppp_up deskbar notifier. Nothing in the FreeBSD netstack code bring us such support. That's something we must keep, because it will protect userland API from changes in the core stack. > * even DHCP is missing! :( Yeah, but I'm the one to blame for that, I never help to integrate it in our stack as I should have the guy who submit us one possible implementation. > For R1.x we will also want to have: > * WiFi > * IPv6 > * IPsec > * VPN > * WiMAX > * Bluetooth > * ... Wifi support for R1, yeah. The rest is really R2. > So, since LWKT and CPU-affinity are not acceptable let's simply port > FreeBSD. That should be much easier, anyway. That's my feeling too. But it should block quick and dirty bug fix to our current code. That's the magic of branching development! - Philippe