On Fri, Oct 1, 2021 at 10:16 AM Olof Johansson <olof@xxxxxxxxx> wrote: > > 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 If the answer is, "we don't have a solution for that" then that's fine. I'm not an expert at Kconfig configurations and am asking if there is already a way to handle this. To me it sounded like there might be a solution already due to this policy of "we don't allow disabling drivers that are essential." I'll wait for Krysztof to respond (or someone who has a potential solution) before I dig into this deeper. --Will
