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

[Olof Johansson]

On Fri, Oct 1, 2021 at 9:51 AM Will McVicker <willmcvicker@xxxxxxxxxx> wrote:
>
> On Fri, Oct 1, 2021 at 9:00 AM Olof Johansson <olof@xxxxxxxxx> wrote:
> >
> > On Fri, Oct 1, 2021 at 4:59 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > >
> > > Hi Olof,
> > >
> > > On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson <olof@xxxxxxxxx> wrote:
> > > > A much more valuable approach would be to work towards being able to
> > > > free up memory by un-probed drivers at the end of boot. That would
> > > > possibly benefit all platforms on all architectures.
> > >
> > > We used to have such a functionality in arch/ppc (not arch/powerpc!),
> > > where code/data could be tagged __prep, __chrp, or __pmac, to put it
> > > in a special section, and to be freed with initdata when unused.  It
> > > was removed in v2.6.15[1], as the savings weren't worth the hassle.
> > > In a more fragmented space like arm the memory lost due to alignment
> > > of the sections would be even more substantial.
> >
> > Yeah, the balance between per-platform code size and overall kernel
> > code size shifted over time to a point where it wasn't as meaningful
> > on ppc.
> >
> > > Another problem is to know when is the end of the boot, especially
> > > with deferred probing.
> >
> > Most of this code either has a module_init() or an initcall that
> > actually registers the drivers and/or probes for the platform and does
> > the work.
> >
> > This means you can have a late equivalent hook/initcall that
> > determines whether this path ended up being probed/used. If it wasn't,
> > you can then unregister and flag the corresponding memory to be freed
> > at the end, and would take out the heuristics and guessing on needing
> > to do it automatically from the code path that's doing said freeing.
> >
> >
> > -Olof
>
> First off, I appreciate the constructive conversations and I
> understand the ask here. So I'd like to close the "we don't want this"
> and "this isn't possible" conversation. We have already proven
> downstream that it is in fact possible to modularize these drivers on
> other SoCs (mentioned earlier if you missed it) and I'd like to direct
> the conversation towards verifying/testing here instead of negatively
> arguing about how SoC vendors aren't upstreaming their drivers. I
> think everyone understands that, but unfortunately I have no control
> over that even though I would love everyone to work upstream directly.
>
> I am fine with forcing these drivers to always be enabled in some form
> upstream even though it doesn't really make much sense for a generic
> kernel that will run on Qualcomm, Exynos, Mediatek, (you name it) SoC
> devices. I thought about how to do this yesterday and wasn't able to
> come up with a proper solution that didn't always force this driver to
> be a module when CONFIG_MODULES is enabled.

This line of reasoning: "I couldn't think of a better option" made us
merge a userspace ABI some time ago that within a few months was
replaced with a better solution. In that case it was the kernel
headers bundling with a build (extending the vmlinux size by a lot),
that seemed to have no concerns about binary growth. Not all that far
after that went in, the BPF folks came up with a solid solution for
CO-RE by introducing BTF, etc.

So, the argument "I can't think of a better solution" is a local
maxima that we shouldn't settle for if there's a likely better global
maxima available with a bit more time/effort. If we say "this problem
is worth solving but this doesn't seem to be the solution we want to
go for" we might actually be better off long-term.


-Olof