Message-ID: <87k05lowpr.fsf@mpe.ellerman.id.au>
Date:   Fri, 30 Sep 2022 22:47:28 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Lukas Bulwahn <lukas.bulwahn@...il.com>
Cc:     kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org,
        Nicholas Piggin <npiggin@...il.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH] powerpc: update config files

Lukas Bulwahn <lukas.bulwahn@...il.com> writes:
> On Fri, Sep 30, 2022 at 9:42 AM Michael Ellerman <mpe@...erman.id.au> wrote:
>>
>> Lukas Bulwahn <lukas.bulwahn@...il.com> writes:
>> > Clean up config files by:
>> >   - removing configs that were deleted in the past
>> >   - removing configs not in tree and without recently pending patches
>> >   - adding new configs that are replacements for old configs in the file
>> >
>> > For some detailed information, see Link.
>> >
>> > Link: https://lore.kernel.org/kernel-janitors/20220929090645.1389-1-lukas.bulwahn@gmail.com/
>>
>> Ideally I'd like a list in the change log of each symbol and why they're
>> being removed/changed. It's pretty easy to accidentally drop something
>> otherwise.
>>
>> I think this is the list in this case:
>>
>> Renamed:
>>   - CONFIG_PPC_PTDUMP -> CONFIG_GENERIC_PTDUMP
>>     e084728393a5 ("powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP")
...
>>
>> I'll fold that into the change log.
>
> Sure. Go ahead. I have provided all information I collected in the
> linked email (and this information drove my scripts to take actions)
> and I am happy to provide it in any form a maintainer may think is
> good for them. But I assume you did this with a simple script
> yourself.

I did it manually actually - just a bunch of "git log -G <symbol>".
A script would have been better :)

> After going through the changes of Kconfig from the last decade, it
> seems feasible that the information on Kconfig changes is actually
> maintained somewhere and that would allow updating of arbitrary kernel
> configs to newer kernel versions. It is not completely out of reach at
> least.
>
> And to really improve the situation, I would like to reduce all these
> defconfigs in the repository to minimal kernel fragments that really
> focus on what these config for specific machines intend to tell. E.g.,
> these configs below (powerpc-configs) are about ensuring specific
> hardware support, not about setting "CONFIG_CRYPTO_XYZ" one way or the
> other. That is actually just "noise".

Yes I agree. In most cases for a lot of options we just want whatever
the default is for that subsystem.

> I do not know how to do this right yet, but with a bit of
> experimentation and investigation, I might come with a first idea and
> then we will see.

IMHO the best solution we have at the moment is generating the configs
with merge_config.sh.

See for example the way our ppc_defconfig is generated:

PHONY += ppc_defconfig
ppc_defconfig:
	$(call merge_into_defconfig,book3s_32.config,)

$ cat arch/powerpc/configs/book3s_32.config
CONFIG_PPC64=n
CONFIG_PPC_BOOK3S_32=y

Everything else just gets the default.

We have some more fully featured examples too, see
arch/powerpc/Makefile.

There's a few drawbacks of that technique though.

One is that those generated configs aren't shown in 'make help'.

And the other is that there's no way to run something like savedefconfig
on those .config files to minimise them.

You have to expand them out into a full .config, run savedefconfig on
that, and then manually grep through the .config to find any symbols
that are no longer needed. You also need to be careful that any symbol
that's no longer needed is no longer needed for all the generated
configs that use that .config file.

cheers

Powered by blists - more mailing lists