> Followup to: <199708150756.DAA18440@dcl.MIT.EDU>
> By author: "Theodore Y. Ts'o" <tytso@MIT.EDU>
> > In general this brings up the question of whether we want to enforce a
> > requirement that people upgrade to glibc when we move forward to the 2.2
> > kernel.....
> >
>
> My opinion is: 2.2, probably not (unless it is *way* late); 2.4
> probably, as by then we're really going to need things that break
> backward compatibility due to silly limits.
2.2 will have to support libc5 anyway for binary compatibility, but
I think it's OK to say "If you want to use new 2.2 features use glibc".
It was the same way with libc5/2.0 - with libc4 it was impossible to
use many 2.0.x features.
One problem is the definition of "new 2.2 features" though: e.g. if
I need to recompile bash to kill processes with pid >2^16 (I think
kill() already uses 32bit pid_ts but you get the idea) that's a different
issue. I think it should be tried to keep the functionality that's already
in 2.0 backward compatible to libc5. For the pid/tid issue that's not
easy though.
-Andi