Re: NPTL support in 2.4 kernel series?

[GOTO Masanori <gotom@debian.or.jp>]

At Fri, 21 Jan 2005 19:51:22 +0100,
Martin Kittel wrote:
> Recently upstream has converted the database kernel from 
> linuxthread-style threading to NPTL. While -at least for i386- 
> linuxthreads is still supported in MaxDB at this time, it will go away 
> in one of the next releases.
> As far as I know there is no NPTL support in 2.4 debian kernels (as for 
> example in some RedHat 2.4 kernels). Is that correct?
> In that case I will have to add a dependency on kernel-image-2.6 or does 
> anyone know of a better way to express a dependency on NPTL style threading?

I don't read these threads entirely, so some opinions may be
duplicated in other messages.

(1) The correct way to detect NPTL availability is: check the result
    value of "getconf GNU_LIBPTHREAD_VERSION":

	gotom@celesta:~> uname -a
	Linux celesta 2.6.8-1-686-smp #1 SMP Mon Sep 13 23:02:39 EDT 2004 i686 GNU/Linux
	gotom@celesta:~> getconf GNU_LIBPTHREAD_VERSION
	NPTL 0.60
	gotom@celesta:~> env LD_ASSUME_KERNEL=2.4.1 getconf GNU_LIBPTHREAD_VERSION
	linuxthreads-0.10

    You can check it in your wrapper script.  If your wrapper script
    detects NPTL unavailability, you can put warning message.

    One problem is old libc6 does not include /usr/bin/getconf (until
    2.3.2.ds1-13, it was included in libc6-dev).  So your package
    should depend on at least 2.3.2.ds1-14 if this method is used
    (because the current libc6 shlib deps is 2.3.2.ds1-4).

(2) Most architectures do not support NPTL currently.  Debian
    glibc-2.3.2.ds1-20 supports NPTL on i386, amd64, ia64 and s390.
    So your package is available on only four architectures.

    (We have plan to add NPTL support for alpha, ppc and ppc64 in the
     next glibc update.  However, currently NPTL is not supported even
     in upstream cvs on arm (EABI update), mips (tls register
     discussion), hppa (Hurrah Carlos O'Donell), m68k (slow speed is
     everytime big problem in computer history).  It's sure that hurd
     and *bsd are out of scope with NPTL.)

(3) NPTL is POSIX thread library - I wonder why your package has to
    depend on NPTL.  It's sure there're a lot of incapability to
    handle the whole POSIX threading requirement with linuxthreads -
    but it has basic features to use pthread.  Depending on the
    specific implementation is not good idea, IMHO.  Martin, I would
    like to know why such requirement is needed.

(4) In general, depending on the specific kernel package causes
    various problems as other mails are already mentioned.  MaxDB
    should not use check kernel version because it's related with
    threading system, not kernel version.

    However some packages really needs kernel version checking - one
    example is glibc package.  It detects old kernel version using
    "uname" in libc6.preinst.  If old kernel version is detected,
    preinst warns with messages and just exits.

    (Note that I'll add "uname detection" not only in preinst but also
     in /etc/init.d in future, though.  I notice that we can possibly
     put a generic kernel version detection mechanism for this kind of
     purpose.)
 
Regards,
-- gotom