Re: + allow-proc-configgz-to-be-built-as-a-module.patch added to -mm tree

[Adrian Bunk <bunk@stusta.de>]

On Sat, Sep 16, 2006 at 08:48:26PM -0400, rossb wrote:
> On 9/16/06, Arjan van de Ven <arjan@infradead.org> wrote:
> >> > In some ways this is a bit risky, because the .config which is used for
> >> > compiling kernel/configs.c isn't necessarily the same as the .config 
> >which was
> >> > used to build vmlinux.
> >>
> >> and that's why a module wasn't allowed.
> >> It's not worth the risk IMO.
> 
> The problem is, the patch is basically s/bool/tristate/ so you can't
> really count on /proc/config.gz anyway.  It's a lot like security
> through obscurity.
> 
> >One hack we could do is make an md5sum or similar of the config and
> >stick that somewhere which is built in and always available (proc or
> >sysfs or something like that); that can be used to validate any config
> >basically to be "correct matching". In fact we could even make it
> >(optionally) part of the VERMAGIC to avoid any kind of mismatch at all.
> 
> Not a bad idea, but I think you want to be able to edit your config
> before compiling modules.  In particular, you might want to turn
> something from off to module.
> 
> How about we embed the md5sum of the config in the kernel, make it
> available via /proc or /sysfs and then have /proc/config.gz return an
> error in the event the md5sum doesn't match?

IMHO this all sounds like overdesigning something that is only a quick 
hack that is sometimes handy:

If you don't want to waste kernel memory, set CONFIG_IKCONFIG=n.

If you are building a kernel for a distribution kernel, set 
CONFIG_IKCONFIG=n and place the .config in /boot/config-*
(or a similar place).

We don't need a sophisticated well-defined semantics for the case when 
the .config changes due to additional modules selected or other special 
cases.

>    Ross

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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