Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>]

On Thu, Sep 30, 2021 at 11:01 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Thu, Sep 30, 2021 at 8:15 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@xxxxxxxxxxxxx> wrote:
> > On 29/09/2021 21:48, Will McVicker wrote:
> > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxx> wrote:
> > >> What is more, it seems you entirely ignored Geert's comments. I pointed
> > >> attention to it last time and you just said you will send v2 instead of
> > >> joining discussion.
> > >>
> > >> It's a NAK for this reason - ignoring what Geert brought: you just broke
> > >> distro configs for Exynos.
> > >
> > > First off I did want to chime into the discussion from the previous
> > > patchset, but I felt that Lee and Saravana addressed all your concerns
> > > regarding the intent and feasibility. You also made it clear what the
> > > next steps were that I needed to take.
> >
> > One of the steps was problem with distros using everything as modules.
> > They should not receive these drivers as modules.
> > Reminder: these are essential drivers and all Exynos platforms must have
> > them as built-in (at least till someone really tests this on multiple
> > setups).
>
> Agreed. I absolutely love the work of the GKI developers to turn more
> drivers into loadable modules, but the "correctness-first" principle is
> not up for negotiation. If you are uncomfortable with the code or the
> amount of testing because you think it breaks something, you should
> reject the patches. Moving core platform functionality is fundamentally
> hard and it can go wrong in all possible ways where it used to work
> by accident because the init order was fixed.

Exactly.
And patches to change this that haven't been tested at all should be
very clearly marked that way.

> > > You said that upstream supports a generic
> > > kernel, but I argue that the upstream "generic" arm64 kernel can't be
> > > considered generic if it builds in SoC specific drivers that can be
> > > modules.
> >
> > Good point, but since having them as modules was not tested, I consider
> > it as theoretical topic.
>
> I actually disagree strongly with labelling the kernel as "non-generic"
> just because it requires platform specific support to be built-in rather than
> a loadable module. This has never been possible on any platform
> I'm aware of, and likely never will, except for minor variations of
> an existing platform.

There seem to be two different meanings for a "generic" kernel:
  1. To me, a generic kernel is a kernel that can boot on a variety of
     hardware platforms. and will operate correctly with all expected
     functionality.  That is, it should include[1] drivers for all that
     hardware.
     Examples of this are arm/multi_v7_defconfig and arm64/defconfig.
  2. To GKI, a generic kernel is a minimal kernel that doesn't include
     any[2] hardware-specific drivers, and has loadable modules for
     all[2] hardware-specific drivers. Before loading these modules, it
     can run an application on the CPU, but it cannot do any I/O to real
     hardware.

[1] Developers usually want the drivers builtin, distros want them
     modular.
[2] On arm/arm64, this must rely on the GIC and architectured timer
    being built-in (AFAIK these cannot be modules yet), and thus
    precludes booting on Cortex A9 and older that lack GIC and/or
    architectured timer as their primary interrupt controller and timer.
    I'm wondering how this works on other architectures with
    less-standardized interrupt controllers and timers?

> Look at x86 as an example: there are less than a dozen SoC platforms
> supported and they are incredibly similar hardware-wise, but the kernel
> is anything but "generic" in the sense that was mentioned above.
> Most of the platform specific drivers in arch/x86/platform and the
> corresponding bits in drivers/{irqchip,clocksource,iommu} are always
> built-in, and a lot more is hardwired in architecture code as PCI
> quirks or conditional on cpuid or dmi firmware checks.

Indeed. X86 has less variability in the hardware than other
architectures, and has all the critical drivers built-in or in firmware.
Where there have been big differences (remember Voyager?), x86 never
had the option to have a generic (in the meaning of 1 above) kernel
(but James did try, cfr. https://lwn.net/Articles/328469/).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds