linux-kernel - Re: [PATCH] mm: Make CONFIG_FRAME

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190115172234.GA991@infradead.org>
Date:   Tue, 15 Jan 2019 09:22:34 -0800
From:   Christoph Hellwig <hch@...radead.org>
To:     Olof Johansson <olof@...om.net>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-mm <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jan Kara <jack@...e.cz>
Subject: Re: [PATCH] mm: Make CONFIG_FRAME_VECTOR a visible option

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.