Mike, I think you have a good plan. Retiring the 2.4 headers sounds like the right thing to do. Building glibc against 2.6 and enabling backwards compatibility with older kernels should not be problematic. It all sounds good from a maintainability and stability perspective.
Nothing should break in theory, but of course in this line of work there is no guarantee that there won't be unexpected transition problems for real users on real systems - but you know that already. With some reasonable amount of testing I think it is a great idea. -Daniel On 2/17/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
now that the 2.6 headers have entered a sane state and are *quite* nice to work with, i have no inclination whatsoever to touch unsanitized headers (keep your puns to yourself :p) so here's the question i pose: what to do ? people file bug reports saying "package FOO fails to build with linux-2.4.xx headers" ... my answer is "well, that sucks, but package FOO is not going to be changed as it builds correctly with sanitized linux-2.6.xx headers" do we want to try and maintain our own sanitized 2.4 headers ? this would require our own git tree as trying to do development on a patch-based setup is an exercise in insanity ... or perhaps we want to unmask the sanitized 2.6 headers for use on a 2.4 profile ? the core ramifications: beneficial actually; we tell glibc what the min kernel version it needs to run on (2.4.1 currently), and it will enable all features required between that and whatever kernel version your headers are ... so if you were to upgrade your kernel, glibc would automatically take advantage of the newer system calls -mike
-- [email protected] mailing list
