Re: Glibc-based Debian GNU/KNetBSD
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)
Reply to: