linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Olof Johansson <olof@lixom.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jan Kara <jack@suse.cz>
Subject: Re: [PATCH] mm: Make CONFIG_FRAME_VECTOR a visible option
Date: Tue, 15 Jan 2019 09:17:30 -0800	[thread overview]
Message-ID: <CAOesGMg4hd8z=2FVDTYMiuKzHnobNLnncV37j77BA+gQGg=heg@mail.gmail.com> (raw)
Message-ID: <20190115171730.bem8DZ6oRqZLGZFdqsN8sqR7WUZ7F5apN0CiuROg5zo@z> (raw)
In-Reply-To: <20190115170510.GA4274@infradead.org>

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


  reply	other threads:[~2019-01-15 17:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15 16:44 Olof Johansson
2019-01-15 17:05 ` Christoph Hellwig
2019-01-15 17:17   ` Olof Johansson [this message]
2019-01-15 17:17     ` Olof Johansson
2019-01-15 17:22     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOesGMg4hd8z=2FVDTYMiuKzHnobNLnncV37j77BA+gQGg=heg@mail.gmail.com' \
    --to=olof@lixom.net \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox