On Mon, Dec 01, 2003 at 10:12:08PM -0500, Nathan Hawkins wrote: > On Tue, Dec 02, 2003 at 01:52:01AM +0100, Robert Millan wrote: > > > > Please avoid the "third party" euphemism. If you want to run non-free > > software > > on a Glibc-based system, you can use the NetBSD libc since it's no technical > > problem to provide it as alternative (ala Linux libc5) > > He's referring to source compatibility. On BSD's, third party seems to > mostly mean just about anything not in the base system. NetBSD has > binary emulation for Linux. That takes care of the non-free stuff, since > that's far more available on Linux than for NetBSD.
We have source compatibility with all other Glibc-based GNU variants, which includes such a popular system as GNU/Linux. I think it's much more compatibility than what the NetBSD libc can provide. > No, _you_ are underestimating the complexities. There is a very large > difference between something like libpth or linuxthreads (which are > either entirely based in userspace, or require minimal support from the > kernel), and the very kernel-specific implementations being used in > NPTL, FreeBSD's libkse or NetBSD's libpthreads. The newer threads > packages are targeting drastic improvements in performance, Posix > compliance, stability, and scalability. And from what I understand, > they're getting them. > > [...] Thanks for clarifiing. Well I don't see the point of discussing all this at this early point, but since all of you are insisting.. In short term, we can use non-preemptive threads (or linuxthreads) without much problem. If there are API incompatibilities with pthreads standard (which there shouldn't be), we fix them. In long term, we can either: - Port NPTL (this makes sense since NPTL is the library Hurd developers are targetting, for example). - Port libkse and libpthreads. We'd have to integrate it with Glibc interfaces, and reformat API to be POSIX compliant if applicable. And don't tell me the long term solutions are "too much work". They're long term for some reason. The system is pretty usable with non-preemptive thread emulation. What is more relevant from the portability perspective is to provide POSIX threads. We can provide POSIX threads with libpth but AFAICS libkse/pthreads are not POSIX threads compliant. If that is the case, note that it is much more detrimental for the port to provide non-standard threads with high performance than to provide POSIX threads even if they use a 100% userspace non-preemptive emulation (libpth). -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion)
