public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
	Nicholas Piggin <npiggin@gmail.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc: update config files
Date: Fri, 30 Sep 2022 22:47:28 +1000	[thread overview]
Message-ID: <87k05lowpr.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <CAKXUXMxe5EagwsQVyt_WLf2mMXZbUqzaEaiUjBj9ZwRRZywx0g@mail.gmail.com>

Lukas Bulwahn <lukas.bulwahn@gmail.com> writes:
> On Fri, Sep 30, 2022 at 9:42 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>> Lukas Bulwahn <lukas.bulwahn@gmail.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

  reply	other threads:[~2022-09-30 12:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 10:15 [PATCH] powerpc: update config files Lukas Bulwahn
2022-09-30  7:42 ` Michael Ellerman
2022-09-30  7:53   ` Lukas Bulwahn
2022-09-30 12:47     ` Michael Ellerman [this message]
2022-10-04 13:26 ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k05lowpr.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=christophe.leroy@csgroup.eu \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=npiggin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox