Re: [ANNOUNCE] linux-libc-headers 2.6.3.0

[Krzysztof Halasa <khc@pm.waw.pl>]

Grzegorz Kulewski <kangur@polcom.net> writes:

> But how synchronize kernel development with glibcs (+ all other C libs + 
> all other programs that must interface directly with the kernel)?

The kernel API should be stable enough, at least within stable trees.
Outside stable trees we should still maintain backward compatibility,
except when it comes to things which wouldn't work anyway (non-libc API
such as ipfw/ipchains/iptables etc).

> When kernel developers want to stop using something, how they should tell 
> that to glibc developers and others.

They should not stop :-)
Adding things is another story.

> Most admins change kernels more often than all other programs and libs 
> and these programs can potenitially not be updated yet.

I don't think so.
Applying a kernel patch usually doesn't change the API. Changing kernel
config should never change the API.

> My proposal is to move these things from linux-common to linux-userland 
> instead of removng them from the kernel immendiatelly.
> So no compatibility with user program and libs will be broken (and after a 
> few releases of kernel, when all programs and libs will be updated, these 
> things can be removed completly from kernel headers of all three types).

Things which are IMHO not options:
- removing kernel headers (i.e. headers which are required by kernel
  files to compile) from the kernel tree,
- duplicating kernel header definitions in external packages (a straight
  copy for distro users is ok, things which need maintenance aren't).
  Existing duplicates should be dealt with.
-- 
Krzysztof Halasa, B*FH