Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

[Willy Tarreau]

Hi Enric,

On Sun, Oct 11, 2020 at 07:05:55PM +0200, Enric Balletbo i Serra wrote:
> For arm64 (i.e : arm64_defconfig):
>     1. Someone renames CONFIG_A to CONFIG_AB, sends a patch, and as he did a
> grep, the patch modifies all the defconfigs.
>     2. The patch is accepted and merged in linux-next.
>     3. KernelCI builds linux-next, boots the kernel on the hardware and all the
> tests continue passing.
> 
> 
> For x86:
>     1. Someone renames CONFIG_A to CONFIG_AB, sends a patch and as he did a grep
> the patches modifies all the defconfigs.
>     2. The patch is accepted and merged in linux-next.
>     3. KernelCI builds linux-next, boots the kernel on the hardware, and some
> tests start to fail or are skipped.
>     4. The maintainer is noticed about the behavior change, so he will need to
> look at the problem, and find it.
>     5. The maintainer sends a patch.
>     6. The patch is accepted, but he needs to tag the release as per kernel <
> x.y.z version it should use CONFIG_A and for kernel > x.y.z it should pick
> CONFIG_AB.
>     7. KernelCI builds linux-next, boots the kernel on the hardware and all the
> tests pass again.

Previously I thought I understood your needs, but now I don't anymore. You
seem to be saying that you're not testing *anything* outside of defconfig,
and that as such you'd like defconfig to be complete enough to provide good
coverage. This sounds a bit odd to me. And what if in the arm64 case, the
CONFIG_YOUR_V4L2_DEVICE is *not* added to defconfig ? You're in the same
situation.

We all know it's not fun to have to deal with local config snippets, but
as soon as you plan to boot on a specific hardware, this is unavoidable.
Also, config symbols are rarely renamed. Most often they are moved under
new entries (e.g. CONFIG_VENDOR_FOO) which are enabled by default, so
that updating your old configuration using "make olddefconfig" is enough
to update it.

What I'm understanding from your proposed change is not to support
KernelCI, but to support Chromebooks by default. This could make more
sense if that's a relevant platform whose support is currently limited
by default, I'm not able to judge that, but at least it seems to me
this would make more sense than having specific configs for KernelCI.

Just my 2 cents,
Willy