Messages in this thread |  | | From | Geert Uytterhoeven <> | Date | Wed, 4 Dec 2019 09:04:49 +0100 | Subject | Re: [PATCH 1/2] x86_64_defconfig: Normalize x86_64 defconfig |
| |
Hi Krzysztof,
On Wed, Dec 4, 2019 at 2:15 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > On Tue, 3 Dec 2019 at 18:01, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Tue, Dec 3, 2019 at 10:26 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > On Tue, 3 Dec 2019 at 17:05, Enric Balletbo i Serra > > > <enric.balletbo@collabora.com> wrote: > > > > On 3/12/19 3:15, Krzysztof Kozlowski wrote: > > > > > On Tue, 3 Dec 2019 at 05:18, Enric Balletbo i Serra > > > > > <enric.balletbo@collabora.com> wrote: > > > > >> > > > > >> make savedefconfig result in some difference, lets normalize the > > > > >> defconfig > > > > >> > > > > > > > > > > No, for two reasons: > > > > > 1. If running savedefconfig at all, split reordering items from > > > > > removal of non needed options. This way we can see exactly what is > > > > > being removed. This patch moves things around so it is not possible to > > > > > understand what exactly you're doing here... > > > > > > > > Ok, makes sense, I can do it, but if you don't really care of having the > > > > defconfig sync with the savedefconfig output for the below reasons or others, > > > > that's fine with me. > > > > > > > > The reason I send the patch is because I think that, at least on some arm > > > > defconfigs, they try to have the defconfig sync with the savedefconfig output, > > > > the idea is to try to make patching the file easier, but I know this is usually > > > > a pain. > > > > > > Till I saw DEBUG_FS removal and Steven's answer, I was all in in such > > > patches from time to time. However now I think it's risky and instead > > > manual cleanup of non-visible symbols is better. > > > > IMHO, it's the maintainer's responsibility to refresh the defconfig(s) > > regularly, from known good config(s). > > > > I.e. you start from a known good .config, run "make oldconfig", verify > > the changes by comparing the .config before/after, and run "make > > savedefconfig" afterwards. > > > > You do not run blindly "make <my>_defconfig && make savedefconfig", as > > that means you'll miss out on new options you may want, and will loose > > old options that are no longer selected by other options. > > Instead of keeping this known good config somewhere outside it should > be just equal to defconfig. There is no point to trim it with > savedefconfig and then later experience missing options (because some > option was a dependency but now is not). Instead, all visible options > (possible to select) should be explicitly defined by defconfig to > avoid what happened with DEBUG_FS.
While I agree that would fix the issue, it would revert to the situation before we had savedefconfig. Hence it would cause much more churn to the checked-in defconfig files, which is the reason why savedefconfig was introduced in the first place....
> I assume here that when removing > non-visible options from dependency, all defconfigs would be updated.
I'm afraid that part will never happen...
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
|  |