All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joachim Wiberg <troglobit@gmail.com>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Masahiro Yamada <masahiroy@kernel.org>
Cc: buildroot@busybox.net
Subject: Re: [Buildroot] [PATCH 3/4] Rename custom kernel defconfig files to *_defconfig
Date: Fri, 31 Dec 2021 11:46:33 +0100	[thread overview]
Message-ID: <afafa25f-5c4c-75e5-7dfb-da8f93204701@gmail.com> (raw)
In-Reply-To: <20210320225648.5c8d0cb4@windsurf.home>

Hi everyone,

On 3/20/21 10:56 PM, Thomas Petazzoni wrote:
> On Thu, 18 Mar 2021 07:28:48 +0900
> Masahiro Yamada <masahiroy@kernel.org> wrote:
>> There is no consistency in file names for
>> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE. Some are suffiex with "defconfig",
>> and some with ".config".
> The *vast* majority of them are named .config. Only three use
> -defconfig or _defconfig. Please normalize on .config, not the opposite.

just to tie up some loose ends.  In
CAK7LNARM_nzn39T0v46XWmLYE1u-DHi65Odm_w9+vxhc6c0x6Q@mail.gmail.com, (Re:
[Buildroot] [PATCH 1/2] qemu_arm_versatile: switch to in-kernel
defconfig + fragment) ...

On 3/16/21 3:55 PM, Masahiro Yamada wrote:
> Maybe we can give _defconfig suffix to
> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE,
> and .config to BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES.
>
> This goes along with the naming rule in the upstream kernel.

If I understand correctly, in Buildroot we have sort of standardized on
.fragment for .config fragments, both for Linux and BusyBox.  But it may
be a bit confusing, since this nomenclature is not used consistently.

From a single linux.config file in board/ it's currently not possible to
know if it's a full kernel .config or a .fragment without looking in the
corresponding Buildroot _defonfig for that target.

So we should try to clean this up a bit, but what should it be?

  1. Enforce current best practices, or
  2. Radically rethink our current nomenclature?

Personally I rather like Masahiro's suggestion to follow Linux kernel
naming rules.  A linux.defconfig (or linux_defconfig) might be better
than linux.config, which in turn would allow us to use linux.config for
fragments.  The same could apply to BusyBox configs as well.  In either
case we should probably update examples and/or add a section on naming
things (policy) to the manual.

I can help out here with both tasks, take over Masahiro's patch series
if necessary, and suggest additions to the manual.

What do you think list?


Best regards
 /Joachim
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2021-12-31 10:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 22:28 [Buildroot] [PATCH 1/4] qemu_arm_versatile: switch to in-kernel defconfig + fragment Masahiro Yamada
2021-03-17 22:28 ` [Buildroot] [PATCH 2/4] qemu_arm_versatile_nommu: " Masahiro Yamada
2021-03-17 22:28 ` [Buildroot] [PATCH 3/4] Rename custom kernel defconfig files to *_defconfig Masahiro Yamada
2021-03-20 21:56   ` Thomas Petazzoni
2021-12-31 10:46     ` Joachim Wiberg [this message]
2021-03-17 22:28 ` [Buildroot] [PATCH 4/4] Rename custom kernel config fragment files to *.config Masahiro Yamada

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=afafa25f-5c4c-75e5-7dfb-da8f93204701@gmail.com \
    --to=troglobit@gmail.com \
    --cc=buildroot@busybox.net \
    --cc=masahiroy@kernel.org \
    --cc=thomas.petazzoni@bootlin.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.