Re: [klibc] klibc and what's the next step?

[Olaf Hering <olh@suse.de>]

 On Tue, Jul 11, H. Peter Anvin wrote:

> Olaf Hering wrote:
> >"It would be nice if ..." someone can build a list of things that
> >changed over time. Say from 2.0.0 to 2.6.18. Just struct layouts and 
> >defines.
> >
> >I havent tried it, but one would hope that the /bin/ls from SuSE 5.3 still
> >works today.  Guess its time for me to actually try that the next days.
> 
> You know how much code there is in glibc to make your /bin/ls still work?

I heard about that, but did never inspect that code.

My point is:
I see all day that people use some fixed distro for kernel development,
thats their stable base. In my case, 2.4.19 based SLES8 for 2.6
development. 2.6.5 based SLES9 for todays kernel. In a few weeks, they
will move on to 2.6.16 based SLES10. Same thing with other distros.

This means their tools continue to work, eventually they have to upgrade
a few things to test newly added features. Thats what everyone on this
list does all day. It means also that regression testing is possible.
One can even boot a 2.4 kernel in SLES9 to try things out, despite the
fact that many boot scripts rely on sysfs. So I dont see why a kinit
that knows about a range of kernels should not be possible. No idea how
hairy device-mapper, lvm or evms support is, the "standard" tools
appearently cope with interface changes.
If you decide to drop support for 2.6.16 in 3 years, thats ok. But not
in 3 months please.

And to give a negative example for great regression test opportunities:
You guessed it, SLES10 has a udev that cant handle kernels before 2.6.15.
Great job. I could slap them all day...