[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [IDEA] Developers: your opinion badly needed ! (Was: [PATCH] /proc/config.gz)
From:       Horst von Brand <vonbrand () sleipnir ! valparaiso ! cl>
Date:       1998-05-31 23:29:05
[Download RAW message or body]

James Mastros <root@jennifer-unix.dyn.ml.org> said:
> On Sun, 31 May 1998, Riccardo Facchetti wrote:
> > Why ? If you make sure to associate (in some secure way) the running
> > kernel with a file containing the infos, you can have no kernelspace
> > bloating.

> This patch is missing the "secure way" part (as you noted in the snipped
> part below <G>).  At the moment, it isn't really any better then just saying
> "keep kernels in /boot/kernel/foo and System.maps in /boot/System.map-foo,
> where foo=foo".  That's the system I use, and it very rarely fails for me
> (on occasion I forget to copy the System.map -- I could just create a
> makefile target for it, and have essentially your solution, except leaving
> out the fooling around with object files.)

There is the machinery for that, and even more... if you do a "make
install", kernel/${ARCH}/boot/install.sh is run from the Makefile there
with the full version, the the bootimage, the system map and the place
where the kernel is to be stored as arguments. You could hack this makefile
to pass the .configure too, and (f.ex. for RedHat systems, which use
/sbin/installkernel to do the final install) hack that one to store .config
as /boot/Config-${version}.

Secure, but not 100% foolproof. But then, what is? ;-)
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viņa del Mar, Chile                               +56 32 672616

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

[prev in list] [next in list] [prev in thread] [next in thread]