Kernel-headers module and glibc mod changes

[Chuck Mead]

So are we going to have a kernel-headers module or not?

On Thu, 9 Oct 2003, elaine wrote:

>
> Jasper,
>
> Correct (see below). If we decide to 'bless' particular header tarballs
> then they may be put into the moonbase (with an md5 which won't work for
> this approach because at the very least the timestamps in the tarball
> will vary).
>
> I figured this gives us the best of both approaches. I figured defaulting
> to local generation of the module sources is a simple approach.
>
> Unfortunately glibc/POST_INSTALL as I posted it lastnight didn't work
> because 'lin' is disabled unitl 'lin glibc' has completed. As an
> expedient, for the moment I"ve copied the kernel-headers/BUILD file
> actions into POST_INSTALL, but I'm going to see now if I can kill the
> glibc lock prior to starting 'lin -c kernel-headers'.
>
> elaine
>
> > Hi elaine,
> >
> > I'm a bit confused. This works a bit different than I expected.
> >
> > In your new modules you copy the headers from /usr/src/linux after
> > recompiling glibc. This is what niki proposed in the meeting.
> >
> > It is also, I believe, what was rejected in favour of a more static
> > approach to kernel headers, to avoid relying on the kernel-du-jour and
> > the /usr/src/linux symlink that can point anywhere.
> >
> > As I understood it, the idea was to create a static kernel header
> > package, based on the ISO kernel (2.4.22) and keep that package until we
> > are ready to move to 2.6 headers.
> >
> > Please tell me if I'm wrong.
> >
> > 	Jasper
> >
> > PS
> > The module looks good, BTW. I'm sure it will work without problems.
> >
> _______________________________________________
> lunar-dev mailing list
> lunar-dev at lunar-linux.org
> http://dbguin.lunar-linux.org/mailman/listinfo/lunar-dev
>

--
csm
Lunar Project Lead