[PATCH] mm: Make CONFIG_FRAME_VECTOR a visible option

[PATCH] mm: Make CONFIG_FRAME_VECTOR a visible option

[Olof Johansson]

CONFIG_FRAME_VECTOR was made an option to avoid including the bloat on
platforms that try to keep footprint down, which makes sense.

The problem with this is external modules that aren't built in-tree.
Since they don't have in-tree Kconfig, whether they can be loaded now
depends on whether your kernel config enabled some completely unrelated
driver that happened to select it. That's a weird and unpredictable
situation, and makes for some awkward requirements for the standalone
modules.

For these reasons, give someone the option to manually enable this when
configuring the kernel.

Signed-off-by: Olof Johansson <olof@lixom.net>
---
 mm/Kconfig | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 25c71eb8a7dbd..0d80d06d3715b 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -731,7 +731,10 @@ config DEVICE_PUBLIC
 	  the CPU
 
 config FRAME_VECTOR
-	bool
+	bool "Frame vector helper functions"
+	help
+	  Provide some helper functions for frame vectors, to be used
+	  by drivers who operate on userspace memory for DMA.
 
 config ARCH_USES_HIGH_VMA_FLAGS
 	bool
-- 
2.11.0

Re: [PATCH] mm: Make CONFIG_FRAME_VECTOR a visible option

[Christoph Hellwig]

On Tue, Jan 15, 2019 at 08:44:35AM -0800, Olof Johansson wrote:
> CONFIG_FRAME_VECTOR was made an option to avoid including the bloat on
> platforms that try to keep footprint down, which makes sense.
> 
> The problem with this is external modules that aren't built in-tree.
> Since they don't have in-tree Kconfig, whether they can be loaded now
> depends on whether your kernel config enabled some completely unrelated
> driver that happened to select it. That's a weird and unpredictable
> situation, and makes for some awkward requirements for the standalone
> modules.
> 
> For these reasons, give someone the option to manually enable this when
> configuring the kernel.

NAK, we should not confuse kernel users for stuff that is out of tree.

Re: [PATCH] mm: Make CONFIG_FRAME_VECTOR a visible option

[Olof Johansson]

On Tue, Jan 15, 2019 at 9:05 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Jan 15, 2019 at 08:44:35AM -0800, Olof Johansson wrote:
> > CONFIG_FRAME_VECTOR was made an option to avoid including the bloat on
> > platforms that try to keep footprint down, which makes sense.
> >
> > The problem with this is external modules that aren't built in-tree.
> > Since they don't have in-tree Kconfig, whether they can be loaded now
> > depends on whether your kernel config enabled some completely unrelated
> > driver that happened to select it. That's a weird and unpredictable
> > situation, and makes for some awkward requirements for the standalone
> > modules.
> >
> > For these reasons, give someone the option to manually enable this when
> > configuring the kernel.
>
> NAK, we should not confuse kernel users for stuff that is out of tree.

I'd argue it's *more* confusing to expect users to know about and
enable some random V4L driver to get this exported kernel API included
or not. Happy to add "If in doubt, say 'n' here" help text, like we do
for many many other kernel config options.

In this particular case, a module (under early development and not yet
ready to upstream, but will be) worked with a random distro kernel
that enables the kitchen sink of drivers, but not with a more slimmed
down kernel config. Having to enable a driver you'll never use, just
to enable some generic exported helpers, is just backwards.


-Olof

Re: [PATCH] mm: Make CONFIG_FRAME_VECTOR a visible option

[Christoph Hellwig]

On Tue, Jan 15, 2019 at 09:17:30AM -0800, Olof Johansson wrote:
> I'd argue it's *more* confusing to expect users to know about and
> enable some random V4L driver to get this exported kernel API included
> or not. Happy to add "If in doubt, say 'n' here" help text, like we do
> for many many other kernel config options.

It is just like any other library function - you get it with a user.

> In this particular case, a module (under early development and not yet
> ready to upstream, but will be) worked with a random distro kernel
> that enables the kitchen sink of drivers, but not with a more slimmed
> down kernel config. Having to enable a driver you'll never use, just
> to enable some generic exported helpers, is just backwards.

Just develop the damn driver in a kernel tree and let people pull
the whole branch like everyone else: problem solved.