Re: Glibc-based Debian GNU/KNetBSD
Robert Millan <zeratul2@wanadoo.es> writes:
>> > I'm not impressed.
>>
>> Hey, you said that you would be able to avoid having to deal with
>> maintaining the glibc stuff yourself because the "upstream" would do
>> it for you. I doubt that the FSF people will do it, and I doubt that
>> we (NetBSD) are going to do it, so what's left?
>
> It isn't the FSF who maintains Glibc.
Whatever. The point is the maintainers won't do the work for you, so
the "upstream" comment doesn't hold much water.
>> As I said, though, it is likely that the NetBSD folks would happily
>> add needed stuff from glibc to the netbsd libc. I mean, who wants to
>> have a libc that won't run popular third party apps? Of course we'd be
>> amenable.
>
> Please avoid the "third party" euphemism. If you want to run
> non-free software on a Glibc-based system,
That's not what "third party" means. "Third party" means stuff not
provided by The NetBSD Foundation in our releases. The BSD world
doesn't work quite the way the Linux world does in this regard. We
maintain both a kernel and a tightly integrated userland that goes
with it -- anything else, for example, Gnu Emacs, is "third
party". Our pkgsrc infrastructure exists to make it easy to compile
third party software, but we do not claim that Emacs and /bin/ls are
supported the same way.
We've got about 4500 packages in pkgsrc -- a fraction of the number
some folks like Debian support, but quite a number -- and in the
course of making them all work we routinely find that we have to fix
things in NetBSD. For example, programs like xmms have inspired many
changes to our threads system.
Anyway, my statement was very straightforward -- if there are
interfaces that apps need that they don't have, we would obviously
want them in NetBSD's libc so we can run those apps. I don't doubt
that there are things our libc lacks (and that glibc lacks for that
matter) and it would be reasonable to fix them. We're interested in
being as functional and compatible as possible.
>> > Porting to a Glibc-based from another is kids play.
>>
>> You aren't listening. The threads stuff is not kids play.
>> [...]
>
> The threads stuff is not as relevant nor as complicated as you pretend. I've
> been working with libpth
pth is not a real preemptive threads library. It doesn't work very
well as a result. You need kernel support to do threads right, and the
kernel support is necessarily intimately connected to the userland
implementation that interfaces with it.
> At some point we'll study which of porting NPTL or porting the
> pthreads from NetBSD's libc is a more viable option.
You will never port NPTL, period, because to do that would require
that you change the NetBSD kernel, and you aren't in a position to do
that.
"Porting" the pthreads from NetBSD's libc will be a very serious job,
and as I noted will require tracking all the changes that get made in
NetBSD's pthreads engine on a constant basis, because as I said, there
is a protocol that the kernel and userland parts of the pthreads
implementation have to agree on.
If you make any mistakes in altering routines in glibc, since you're
dealing with threads stuff it may take months or years to find all the
heisenbugs that locking code brings in. Ditto, by the way, for bugs in
the thread engine itself.
> If you want to help or propose a solution, that's fine, but stop playing
> devil's advocate which is just a waste of my time.
I'm not playing devil's advocate. I'm trying to tell you the
truth to try to help you. You seem to be unwilling to listen. Thus,
I'll drop out of the conversation. Do whatever you want.
--
Perry E. Metzger perry@piermont.com
Reply to: