> Ingo, how do you handle this sort of backward compatibility in your
> latest pthreads library, or don't you do backward compatibility?
[btw., it's not me doing it but Ulrich Drepper. I'm mostly doing the 'lets
find out how the kernel could help' side of things.]
the proper way of doing this is a way of getting fundamental kernel
capabilities, not the 'probing' of the kernel in various ways. Glibc
starts looking like old ISA drivers trying to do nonintrusive
autodetection: 'lets try this port carefully without disturbing state,
perhaps this feature is there'.
one way to handle this cleanly would be to add a kernel capabilities
bitmask to sysconf(), and backport this to all mainstream Linux kernels
where current glibc is supposed to run. Support for something like this
would be added to glibc the day it's in the main kernel. Eg. glibc has to
symlink in the old pthreads library upon bootup, if the feature-set does
not enable the more integrated threading library.
(nevertheless your patch makes good sense, from an API-cleanliness POV.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/