Hi Lee,

On Thu, Sep 30, 2021 at 2:08 PM Lee Jones [off-list ref] wrote:

On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:

quoted

On Thu, Sep 30, 2021 at 12:56 PM Lee Jones [off-list ref] wrote:

quoted

On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:

quoted

On Thu, Sep 30, 2021 at 11:23 AM Lee Jones [off-list ref] wrote:

quoted

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:

quoted

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).

quoted

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.

quoted

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.

quoted

quoted

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?

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

quoted

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@linux-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