Message-ID: <1dfdf163-9b54-ceae-b178-c566e6109263@collabora.com>
Date:   Sun, 11 Oct 2020 19:05:55 +0200
From:   Enric Balletbo i Serra <enric.balletbo@...labora.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Randy Dunlap <rdunlap@...radead.org>, linux-kernel@...r.kernel.org,
        x86@...nel.org, Collabora Kernel ML <kernel@...labora.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Diego Elio Pettenò <flameeyes@...meeyes.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Willy Tarreau <w@....eu>
Subject: Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

Hi Borislav,

On 11/10/20 17:57, Borislav Petkov wrote:
> On Sun, Oct 11, 2020 at 05:40:27PM +0200, Enric Balletbo i Serra wrote:
>> How do you quantify those things are NOT common enough? Do you have a number?
> 
> I don't want to change the defconfig - you do. So quantifying is in your
> court - not mine.
> 
>> I don't have a number, the only I can tell is that both symbols enable support
>> for I2C, SPI an HS-UART. The AMD one, is found on AMD Carrizo and later
>> chipsets, the Intel one, is found on Intel Skylake and later. I.e Lots of
>> laptops need these to have support for the touchpad.
> 
> That sounds like a step in the right direction.
> 
>> KernelCI is focused on upstream kernel development. KernelCI builds lots of
>> different versions of the kernel, including stable kernels, and maintainers
>> trees. It does tests on real hardware, so having a config supporting as much as
>> possible the x86 hardware that we have in the KernelCI labs will help us to
>> increase the test coverage and catch more issues.
> 
> So those issues - where do you guys report them? Because I've never seen
> one reported by kernelCI, AFAIR. I see 0day bot and syzbot doing such
> reports on a regular basis but none from kernelCI AFAIK. Do you send
> your bug reports to lkml and Cc the relevant parties?
> 

Yes, although probably there is only a chance that you saw for ARM platforms, we
just started to attach x86 hardware to the KernelCI labs (apart from some qemu
instances).

They all can be found here:
https://groups.io/g/kernelci-results/messages?start=10:2020:-120


>> Yes, it can. As I said, is a matter of maintenance, if we do this we
>> will have a different workflow for x86 hardware.
> 
> Lemme get this straight - your workflow would do:
> 
> $ make defconfig
> 
> and now here you'd have to add a single command:
> 
> $ .scripts/kconfig/merge_config.sh -m .config .kernelci.config.snippet
> 
> in order to get the symbols you want, enabled.
> 
> I've shown this one because this is how those other configs like
> kvm_guest.config and xen.config work - they're config snippets and they
> get merged with a preexisting config, see scripts/kconfig/Makefile.
> 
> Now, is that additional single command worth "hours of maintenance time"
> or is it something you can do easily? As in:
> 
> 	if (x86)
> 		<command>
> 
> ?
>

Sorry if I didn't explain well, but I am not talking about this workflow, which
of course, is very trivial and actually even implemented in kernelCI. It
actually allows to merge fragments. Let me try explain again.

I'm going to use the arm64 / x86 naming just because for clarity, but basically
is a fragment in the kernel repository vs a fragment on another repository.

So imagine your hardware is attached to a KernelCI lab and want to run
v4l2-compliance tests on that hardware.

For arm64 (i.e : arm64_defconfig)
   1. You send a patch to the list enabling the CONFIG_YOUR_V4L2_DEVICE=m
   2. The patch is accepted and merged in linux-next.
   3. KernelCI builds linux-next, boots the kernel on the hardware, detects a
new v4l2 device, and runs the v4l2-compliance tests.


For x86:
   1. You send a patch to list enabling the CONFIG_YOUR_V4L2_DEVICE=m
   2. The patch is rejected because doesn't fit the requirements (is not common
enough)
   3. If you're lucky someone will tell you to send the patch, to the specific
KernelCI x86 fragment project.
   4. You send a patch to the separate KernelCI x86 project.
   5. The patch is accepted and merged.
   6. KernelCI builds linux-next, boots the kernel on the hardware, detects a
new v4l2 device, and runs the v4l2-compliance tests.


Of course you can skip 1-3 if you know already that. Another example:


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.

Thanks,
 Enric


> Thx.
> 

Powered by blists - more mailing lists