[Buildroot] [PATCH 1 of 2] linux: add linux-update target to save configuration

[Thomas De Schampheleire]

Hi Thomas,

On Wed, Sep 21, 2011 at 9:28 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Hello,
>
> Le Wed, 21 Sep 2011 08:46:15 +0200,
> Thomas De Schampheleire <patrickdepinguin+buildroot at gmail.com> a écrit :
>
>> In analogy to build targets uclibc-update and busybox-update, add linux-update
>> that copies the current configuration to the custom configuration file set in
>> buildroot.
>> This facilitates the work of developers adding support for a specific board
>> to buildroot.
>
> Definitely a good thing to have. However:
>
>  * The name if misleading. "linux-update" "busybox-update": one is not
>   "updating" Linux or Busybox, but rather copying or updating the
>   configuration. So presumably the name of those targets should be
>   changed.

I agree that the name is a bit strange. "busybox-update" and
"uclibc-update" were introduced back in 2007:

>From 6acce2cf1fc2716f030d4939c8b06c6dff4e6543 Mon Sep 17 00:00:00 2001
From: Ulf Samuelsson <ulf.samuelsson at atmel.com>
Date: Wed, 26 Sep 2007 22:12:51 +0000
Subject: [PATCH] Add more management to linux and buysbox packages

>From e2e3006ea30cfc997428853bf71b352663080d14 Mon Sep 17 00:00:00 2001
From: Ulf Samuelsson <ulf.samuelsson at atmel.com>
Date: Thu, 27 Sep 2007 00:18:52 +0000
Subject: [PATCH] Additional management of uclibc

linux-update-config, busybox-update-config and uclibc-update-config
look better indeed...

>
>  * I don't like the existing behaviour of busybox-update and
>   uclibc-update, because they can overwrite the default configuration
>   in package/busybox/busybox-xxx.config or
>   toolchain/uClibc/uClibc-xxx.config. I think those *-update should
>   only take effect if a non-standard configuration file was proposed,
>   as you did for the Linux one.

busybox-update uses $(BR2_PACKAGE_BUSYBOX_CONFIG), and uclibc-update
uses $(BR2_UCLIBC_CONFIG). Both variables can be set to a custom value
through menuconfig, so they definitely are not always standard.
If you want to differentiate them, will you check for a hardcoded value?

But, when a buildroot core developer needs to update one of these
standard files, how does he go about? Would an -update-config file not
be useful for him as well?

>
>  * For the Linux kernel, I do use savedefconfig, so I'd like to see
>   either this "linux-update" thing use savedefconfig, or have a
>   separate option that does the same thing as "linux-update" but using
>   savedefconfig. Maybe "linux-update-config" and
>   "linux-update-minconfig" ?

One disadvantage of the defconfigs generated with savedefconfig is
that they do not contain the full configuration, only the custom
items. This means that a defconfig generated for one release (of
buildroot, linux or whatever) may generate a different configuration
when used on a different release (if in that different release the
defaults changed).

For specific projects, this may be a problem. Suppose you need
uclibc-0.9.31. In a previous release, this was also the buildroot
default. If you generated a defconfig of the buildroot configuration,
the choice for uclibc-0.9.31 would not appear.
Suppose then the project wants to update to a newer buildroot release,
in which uclibc-0.9.32 is the default. The project developer copies
over the defconfig, and suddenly he gets 0.9.32 even though his config
'didn't change'.

Specifically for Linux, I can imagine that developers receive a
working (full) kernel config from their board manufacturer. If they
make a change to it and save it back, their version control system can
easily work out the differences. But if you save a defconfig back,
this resulting delta becomes impractical to read as it doesn't
directly relate to the full config.

So, I would be in favor of keeping these apart, and provide separate
options for saving full configs and defconfigs.

By the way, previously I had a 'config-update' target as well, that
would copy back the buildroot configuration to the applicable
'configs/*_defconfig' file. These were full configs at the time
(2010.11).

Best regards,
Thomas