Date: Sat, 09 Nov 2002 04:05:51 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: bluetooth Message-ID: <3DCCFA1F.7B5F4C01@mindspring.com> References: <Pine.BSF.4.21.0211071328530.5860-100000@InterJet.elischer.org> <038501c286b2$5efb1890$52557f42@errno.com> <20021109.001225.94555950.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"M. Warner Losh" wrote: > I'd go one step farther. I'd say that it would be insane to have more > than one bluetooth stack for FreeBSD. I'd go farther and say that it > would be insane to have more than one bluetooth stack for *BSD. > Bluetooth is too big and specailized for there to be much benefit in > competing stacks. I'll go further... it's insane to have more than one Bluetooh stack period. Are people actively trying to ignore the example of the success of TCP/IP, or what? > I mean look how far the multiple ATM stacks got us. It was a dump > idea to have more than one in the system, and now both aren't very > supported. People had to beg and plead to get the drivers updated, > and only one of the two stacks survived (if I read my commit mail > correctly). I think this had more to do with ATM sucking, more than anything else. I note that NetBEUI isn't supported, even though there was a full stack written by MITRE for FreeBSD, and that X.25 and OSI both have very poor support in FreeBSD, ever since they were both orphaned by the routing code not being updated in those stacks at the same time it was updated in the TCP/IP stack. So ATM isn't really a good negative example for multiple stacks, as much as it's a negative example for useful protocol design. > And look at OLDCARD and NEWCARD. When both were being worked on, both > suffered. OLDCARD got all the bug fixes and new features for a while > when we'd be more ahead today if I'd ported NEWCARD to -stable and > pc98 instead. Having two implementations there was more of a > liability than an asset I sometimes think. Again, I think the problem with both of them has been a serious lack of documentation, more than anything else. The Bus Space code is another good example of code that's not documented well enough for people to use it usefully, or FreeBSD would already support more than 2G of memory on Alpha systems. The problem there is more one of letting replacement code into the kernel, without replacement documentation for the new code that at least matches the documentation for the old code. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DCCFA1F.7B5F4C01>