kernel-headers-2.4 module

[Jasper Huijsmans]

On Fri, Jan 21, 2005 at 03:16:33PM +0100, Moritz Heiber wrote:
> On Thu, 20 Jan 2005 15:36:53 +0100
> Moritz Heiber <moe at lunar-linux.org> wrote:
> 
> > On Thu, 20 Jan 2005 14:22:32 +0100
> > Jasper Huijsmans <jasper at lunar-linux.org> wrote:
> > 
> > > I would choose (b).
> > 
> > mmm .. guess we could put up a script on espresso that does the job
> > automaticly ..
> >  
> > > (c) could be to use redhat (or debian or suse or ...) 2.4 kernel
> > > headers, which have been 'sanitized', like the 2.6 headers. Don't
> > > know if that is needed or if it is available at all.
> 
> So this turns out to be a lot more complicated than I expected it to be.
> Basicly, we might have to have a seperate tarball for every kernel
> module we currently maintain since the patches applied to the -agr or
> -grsec kernels are modfiying the headers too.
> So what should we do?
> 
> Provide one tarball of kernel headers that comes from the 'pure' kernel
> source tree?
> Provide seperate tarballs for every kernel module?
> 
> or ...
> 
> abandon the concept of kernel header modules and go back to linking the
> headers from /usr/src/linux to /usr/include/ .. (I can't remember why we
> opted against staying around that matter .. anybody willing to remind me
> of the reason for it?).
> 
> Regards,
> 
> Moritz

Ok, according to the kernel people (Linus) the header files in /usr/include
should be the ones that were use to build glibc. I don't think they need to be
all that up-to-date, actually.

If applications require special kernel header support they should link to the
actualy kernel headers in /usr/src/linux-<version>/... 

This of course is much harder to get right in a source-based distribution, so
I don't know what the best option is.

Most important thing to prevent, IMO, is that when I recompile glibc while
running a certain kernel (2.6), I can still boot with another (older) kernel 
without problems.

There's also only one 2.6 kernel header package, isn't there? 

	Jasper