Message-ID: <CAMuHMdW96DUXSWOuU3prUAt67pXNe-+CV+6igSuLLwF=k65pUA@mail.gmail.com>
Date:   Thu, 30 Sep 2021 18:09:36 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Will McVicker <willmcvicker@...gle.com>,
        Russell King <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        Tomasz Figa <tomasz.figa@...il.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Saravana Kannan <saravanak@...gle.com>,
        "Cc: Android Kernel" <kernel-team@...roid.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-rtc@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
        Olof Johansson <olof@...om.net>
Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

Hi Lee,

On Thu, Sep 30, 2021 at 2:08 PM Lee Jones <lee.jones@...aro.org> wrote:
> On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:
> > On Thu, Sep 30, 2021 at 12:56 PM Lee Jones <lee.jones@...aro.org> wrote:
> > > On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:
> > > > On Thu, Sep 30, 2021 at 11:23 AM Lee Jones <lee.jones@...aro.org> wrote:
> > > > > I've taken the liberty of cherry-picking some of the points you have
> > > > > reiteratted a few times.  Hopefully I can help to address them
> > > > > adequently.
> > > > >
> > > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > > > 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).
> > > > >
> > > > > > Therefore I don't agree with calling it a "problem" that we select
> > > > > > *necessary* drivers for supported platforms. It's by design - supported
> > > > > > platforms should receive them without ability to remove.
> > > > >
> > > > > > The selected drivers are essential for supported platforms.
> > > > >
> > > > > SoC specific drivers are only essential/necessary/required in
> > > > > images designed to execute solely on a platform that requires them.
> > > >
> > > > Why?
> > >
> > > Because without them the image wouldn't functional on any level.
> > >
> > > But you're right, there is still no requirement for it to be built-in.
> > >
> > > > > For a kernel image which is designed to be generic i.e. one that has
> > > > > the ability to boot on vast array of platforms, the drivers simply
> > > > > have to be *available*.
> > > >
> > > > If the drivers are really essential/necessary/required, this precludes
> > > > running the generic kernel image on the platform that requires them,
> > > > making the kernel not sufficiently generic.
> > >
> > > If they are not at all present, then yes.  However that is not what is
> > > being suggested.  The essential functionality will be provided.  Just
> > > not built-in.
> >
> > I really meant "essential/necessary/required to be built-in".
>
> Then I agree with you.  My position is that if they don't *have* to be
> built-in, then why force it?
>
> > > > > Forcing all H/W drivers that are only *potentially* utilised on *some*
> > > > > platforms as core binary built-ins doesn't make any technical sense.
> > > > > The two most important issues this causes are image size and a lack of
> > > > > configurability/flexibility relating to real-world application i.e.
> > > > > the one issue we already agreed upon; H/W or features that are too
> > > > > new (pre-release).
> > > >
> > > > True, if "potentially".  If not potentially, they must be included.
> > >
> > > I'm not sure what you're trying to say here.  Would you mind elaborating?
> >
> > It was a comment to your "*potentially* utilised on *some* platforms".
> > It is clear they are not used on the other ("not *some*") platforms, but your
> > sentence was unclear whether they are always or only sometimes used on
> > "*some*" platforms.
> > "always" => "not potentially"
> > "sometimes" => "potentially".
> >
> > I hope this makes it more clear.
>
> Not really, but I'll try to clean mine up:
>
> The aim is to have a single kernel (image + modules) that can be
> booted on a plethora of platforms.  For the sake of argument say 10.
> Let's also say that each of the platforms are equal and will be booted
> the same amount of times.
>
> Taking the example above, when I say that the H/W specific drivers
> will only be *potentially* utilised, I mean that they will only be
> bound and probed 1/10 times i.e. when booted on the associated
> platform.  Which means that in the vast majority of boots (9/10) they
> will lie dormant, taking up unnecessary space.
>
> Another way to say this would be; the kernel needs to have the
> capability to boot all of the supported platforms, but it will only
> ever be utilised on one at a time.

That's true even for drivers for "generic" hardware, right?
E.g. arm64 selects ARM_GIC and ARM_GIC_V3, where most (all?)
platforms have at most one of them.

> > > > > Bloating a generic kernel with potentially hundreds of unnecessary
> > > > > drivers that will never be executed in the vast majority of instances
> > > > > doesn't achieve anything.  If we have a kernel image that has the
> > > > > ability to boot on 10's of architectures which have 10's of platforms
> > > > > each, that's a whole host of unused/wasted executable space.
> > > >
> > > > The key here is if the driver is required or not to use the platform,
> > > > and why it is required.  If the requirement comes from some deficiency
> > > > in the kernel code or config system, it should be fixed, if possible.
> > > > And the fix should be tested.
> > > > If it cannot be fixed, the driver should be included, else it would
> > > > preclude running the generic kernel on the affected platform.
> > >
> > > Sorry, I'm not following.
> >
> > It all depends on why the driver is "required to be built-in".
> > Depending on the reason behind that requirement, the driver can be
> > changed from built-in to modular without ill effects on functionality.
>
> Absolutely.
>
> There are cases where drivers simply can't be built as modules.  These
> unavoidable situations are legitimate use-cases and the technology/
> code-base will have to work around these as required.
>
> The argument here is that if they can be separated and have been shown
> to work well in either use-case, then it is my opinion that placing an
> artificial barrier up based mostly on politics is not the correct
> approach.

Agreed.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

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

Powered by blists - more mailing lists