linux-kernel - Re: New Kernel headers vs old Kernel headers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20080530195941.GC5609@1wt.eu>
Date:	Fri, 30 May 2008 21:59:41 +0200
From:	Willy Tarreau <w@....eu>
To:	Marco <marco@...pabay.rr.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: New Kernel headers vs old Kernel headers

On Fri, May 30, 2008 at 01:28:58PM -0400, Marco wrote:
> Hello All,
> 
> I've come across a little discrepancy between the glibc docs and linux
> kernel docs when I was trying to figure out what kernel headers I should
> being using for my cross compiling.  The docs seem to say almost exactly
> the opposite thing.
> 
> For a quick summary: linux docs(headers_install.txt) seem to indicate,
> running glibc compiled against new kernel headers, on an older kernel
> will possibly cause problems.  Where as glib docs(FAQ) indicate glibc
> compiled against new kernel headers, will run fine on an older kernel.
> 
> Can someone shed some light on this (i.e. which is right)?
> 
> Thank you in advance
> 
> Marco Fonseca
> 
> (p.s. I've included the sections from both docs below for easy reference)

IMHO and from experience, the kernel's version is the right one. Also,
it makes some sense, considering that even if you try to run an old
binary on a recent kernel, it generally works while the other way around
is not always true. Note however that what is said in glibc's doc mostly
talks about missing features. They may consider that the glibc offers an
abstraction between the application and the kernel, so that it should be
transparent to the application.

I think the right approach is to base your work on the oldest kernel you
intend to support. That way you'll get most features with the maximum
guarantee of backwards compatibility.

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/