Copying .config to /lib/modules/`uname -r`/kernel

Copying .config to /lib/modules/`uname -r`/kernel

[Pavel Roskin]

Hello!

Many drivers are developed outside the kernel tree.  Many drivers start
their existence as separate projects.  It's essential that they are tested
by the users of particular hardware, even if those users don't want to
recompile their kernels.

There should be a standard place for .config in kernel packages.
/proc/config.gz may or may not be popular with distributors.  Besides, it
only gives information for the currently running kernel, but not for e.g.
newly upgraded kernel before the reboot.

Cannot we just install .config to the same directory as modules?  If the
kernel doesn't support modules, then there is no point to compile any new
modules against it.  But if it does, then we can be sure that the modules
correspond to that configuration file, because the modules and .config
would be installed by the same command.

That's why I prefer the "kernel" subdirectory.  It's fully replaced by
"make modules_install", so that the old .config will go away for sure.

Patch against 2.6.0-test8
=====================
--- Makefile
+++ Makefile
@@ -690,6 +690,7 @@
 	@rm -rf $(MODLIB)/kernel
 	@rm -f $(MODLIB)/build
 	@mkdir -p $(MODLIB)/kernel
+	@cp -f .config $(MODLIB)/kernel
 	@ln -s $(TOPDIR) $(MODLIB)/build
 	$(Q)$(MAKE) -rR -f $(srctree)/scripts/Makefile.modinst

=====================

-- 
Regards,
Pavel Roskin

Re: Copying .config to /lib/modules/`uname -r`/kernel

[Muli Ben-Yehuda]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

On Fri, Oct 24, 2003 at 04:26:12AM -0400, Pavel Roskin wrote:

> Cannot we just install .config to the same directory as modules?  If

What's wrong with /lib/modules/version/build/.config? 

> kernel doesn't support modules, then there is no point to compile any new
> modules against it.  But if it does, then we can be sure that the modules
> correspond to that configuration file, because the modules and .config
> would be installed by the same command.

you need the build symlink to compile a module against this kernel
anyway, because you need its includes, not to mention its build
system. 

Cheers, 
Muli 
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://www.livejournal.com/~mulix

"the nucleus of linux oscillates my world" - gccbot@#offtopic


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Copying .config to /lib/modules/`uname -r`/kernel

[Pavel Roskin]

On Fri, 24 Oct 2003, Muli Ben-Yehuda wrote:

> On Fri, Oct 24, 2003 at 04:26:12AM -0400, Pavel Roskin wrote:
>
> > Cannot we just install .config to the same directory as modules?  If
>
> What's wrong with /lib/modules/version/build/.config?

It's missing on Red Hat Linux.  The reason if that there are differently
configured kernels (e.g. SMP, high memory) that have different binary
packages.  On the other hand, there is just one source package. Binary
packages cannot install .config to the same place, or they will conflict.
That's why they put .config under the name /boot/config/`uname -r` in
every binary package.  Kernel versions include the configuration, so these
files don't conflict.

Using /boot is not standard across distributions.  I think Linux
developers should be the ones who set standard.  If it's /boot then fine,
but .config should be installed somewhere for reference.

Alternatively, there should be some way to extract .config from files
compiled with CONFIG_IKCONFIG.  However, I would prefer a plain text file
that could be used by simply adding "include" in the Makefile.

> you need the build symlink to compile a module against this kernel
> anyway, because you need its includes, not to mention its build system.

The includes are there.  Only autoconf.h needs to be recreated.

-- 
Regards,
Pavel Roskin

Re: Copying .config to /lib/modules/`uname -r`/kernel

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

On Fri, 2003-10-24 at 18:50, Pavel Roskin wrote:
\
> It's missing on Red Hat Linux.

It's not missing. For 2.4 kernels you don't need it to build external
modules against. For the 2.6 kernel rpms
(http://people.redhat.com/arjanv/2.5/ </shamelessplug>) the config is
there as required



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Copying .config to /lib/modules/`uname -r`/kernel

[Pavel Roskin]

On Fri, 24 Oct 2003, Arjan van de Ven wrote:

> On Fri, 2003-10-24 at 18:50, Pavel Roskin wrote:
> \
> > It's missing on Red Hat Linux.
>
> It's not missing. For 2.4 kernels you don't need it to build external
> modules against. For the 2.6 kernel rpms
> (http://people.redhat.com/arjanv/2.5/ </shamelessplug>) the config is
> there as required

That's an interesting approach.  Well, if other distribution follow the
suit and include the /lib/modules/`uname -r`/build directory with the
packages, maybe compiling standalone drivers against precompiled kernels
won't be such a challenge as it is now.

Thank you for you reply.  Please disregard my patch.

-- 
Regards,
Pavel Roskin

Re: Copying .config to /lib/modules/`uname -r`/kernel

[dleonard]

Personally I like to put it in the same place as the kernel itself and the
System.map.  Then I tack the full version number on the end just like I do
with System.map.  Even for non-modular kernels it is frequently convenient
to have access to the .config so when you boot up a random isolinux CD you
know exactly what support you are going to have.

-- 

<Douglas Leonard>
<dleonard@dleonard.net>

On Fri, 24 Oct 2003, Pavel Roskin wrote:

> Hello!
>
> Many drivers are developed outside the kernel tree.  Many drivers start
> their existence as separate projects.  It's essential that they are tested
> by the users of particular hardware, even if those users don't want to
> recompile their kernels.
>
> There should be a standard place for .config in kernel packages.
> /proc/config.gz may or may not be popular with distributors.  Besides, it
> only gives information for the currently running kernel, but not for e.g.
> newly upgraded kernel before the reboot.
>
> Cannot we just install .config to the same directory as modules?  If the
> kernel doesn't support modules, then there is no point to compile any new
> modules against it.  But if it does, then we can be sure that the modules
> correspond to that configuration file, because the modules and .config
> would be installed by the same command.
>
> That's why I prefer the "kernel" subdirectory.  It's fully replaced by
> "make modules_install", so that the old .config will go away for sure.
>
> Patch against 2.6.0-test8
> =====================
> --- Makefile
> +++ Makefile
> @@ -690,6 +690,7 @@
>  	@rm -rf $(MODLIB)/kernel
>  	@rm -f $(MODLIB)/build
>  	@mkdir -p $(MODLIB)/kernel
> +	@cp -f .config $(MODLIB)/kernel
>  	@ln -s $(TOPDIR) $(MODLIB)/build
>  	$(Q)$(MAKE) -rR -f $(srctree)/scripts/Makefile.modinst
>
> =====================
>
> --
> Regards,
> Pavel Roskin
> -
> 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/
>

Re: Copying .config to /lib/modules/`uname -r`/kernel

[Pavel Roskin]

On Fri, 24 Oct 2003 dleonard@dleonard.net wrote:

> Personally I like to put it in the same place as the kernel itself and
> the System.map.  Then I tack the full version number on the end just
> like I do with System.map.  Even for non-modular kernels it is
> frequently convenient to have access to the .config so when you boot up
> a random isolinux CD you know exactly what support you are going to
> have.

Yes, I actually found that scripts/mkspec and scripts/kconfig/confdata.c
in the Linux source already know about /boot/config-`uname -r`, so it's
not just a Red Hat specific thing.  I didn't make enough research.

It looks like the interface to /sbin/installkernel is not very flexible as
it doesn't get .config as an argument.  Anyway, I can provide a patch to
install .config to /boot/config-`uname -r` for all architectures if
anybody is interested.

-- 
Regards,
Pavel Roskin