lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 11 Oct 2020 21:06:22 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Enric Balletbo i Serra <enric.balletbo@...labora.com>
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

On Sun, Oct 11, 2020 at 07:05:55PM +0200, Enric Balletbo i Serra wrote:
> 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)

Well, what if that config option enables hardware which is ARM-only.
Then it doesn't make any sense to enable it in the x86 defconfig.

>    3. If you're lucky someone will tell you to send the patch, to the specific
> KernelCI x86 fragment project.

You lost me here: there's a specific 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:

So this second example confused me even more. Looking at your original
patch, you want this enabled in the defconfig:

config SERIAL_8250_DW
        tristate "Support for Synopsys DesignWare 8250 quirks"
        depends on SERIAL_8250
        select SERIAL_8250_DWLIB
        help
          Selecting this option will enable handling of the extra features
          present in the Synopsys DesignWare APB UART.

and for that you need those other two: X86_AMD_PLATFORM_DEVICE and
MFD_INTEL.

What I don't get is why can't you have a .config.snippet which enables
what you need on the chromebooks and you can have all the serial you
want. And the net card driver for that matter.

And in all that, I still don't get why this is relevant for the upstream
kernel.

By this logic, other projects would start wanting to add more to
defconfig and which would slowly turn into an allmodconfig. So you can
simply build an allmodconfig kernel and do *all* your testing with it,
just like the distros ship an allmodconfig-like kernel. Problem solved.

/me is more confused.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists