[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Glibc-based Debian GNU/KNetBSD

Robert Millan <zeratul2@wanadoo.es> writes:
>> 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.
> This is Debian, and we have around 10000 packages here. Why do we have to
> support installing packages from the NetBSD pkgsrc archive?

Are you deliberately misreading me? I wasn't saying anything about you
supporting pkgsrc. I was explaining what "third party" means in this
context, and why it is that we try to make our libc support everything
we can.

>> > 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.
> I know that.

Then why are you comparing "pth" to the job of making a kernel
assisted pthreads system work? They are unrelated.

>> > 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.
> We can do either.[...]

I give up. If you think you can make NPTL somehow work on an operating
system that doesn't have the kernel support for it, well, good luck to

For the record, if anyone OTHER than Robert is interested in
discussing various things that NetBSD could do to make it easier for
people to use our stuff with Debian, please get in touch with
me. We're always interested in making improvements to our available
APIs etc.


Reply to: