linux-kernel - Re: [GIT PULL] Driver core update for 4.7-rc1

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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 21 May 2016 09:59:09 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	William Breathitt Gray <vilhelm.gray@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Guenter Roeck <linux@...ck-us.net>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Driver core update for 4.7-rc1

On Sat, May 21, 2016 at 9:31 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> We're not suddenly enabling ISA on x86-64 after having successfully
> gotten rid of that insane crap long long ago.
>
> If you have *specific* dribvers that are actually relevant for some
> reason, make those ones available based on other options. For example,
> we've had the ISA_DMA_API config option to say "we support a subset of
> ISA, even when we don't actually want to ever see actual plug-in ISA
> cards".

I am planning on committing something like the attached.

Note that anything that added "depends on ISA" because of the other
patches will now be disabled on x86-64, even if that driver wasn't
disabled before.

Added Linus Walleij and Guenther Roech to the cc because of the
drivers that I'm aware that did this.

To repeat: I'm not at all interested in enabling random old drivers on
x86-64. Any driver enablement needs to be done on a one-by-one basis,
after having actually gotten TESTING, and after having had people make
sure that we don't get tons of new warnings like we did with the
"let's just enable ISA randomly" approach.

I'm ok with enabling some "ISA_BUS_API" support (like we have
ISA_DMA_API) that allows people to enable drivers one-by-one as they
are converted to a convenience function. The patch series seems to
have had that kind of approach initially.

I'd suggest doing that ISA_BUS_API config option as a *general* thing
(not arch-specific), and make it start out like

      config ISA_BUS_API
          def_bool ISA

which means that everybody gets it, and if ISA was enabled, it will be
enabled automatically. Then, architectures that do *not* enable ISA
itself (like x86-64), could choose to have a config option like

    config ISA_BUS
        bool "support ISA-style drivers on modern systems" if (x86 && EXPERT)
        default y
        select ISA_BUS_API

or something, which means that ISA_BUS_API would then get enabled (but
not ISA itself).

That's similar to what we do today with ISA_DMA_API, except we made
the mistake of making all the different architectures define the
ISA_DMA_API option.

It's the wholesale "enable random crap" that I will not accept. Not
even if there is then "hide the crap again when it causes warnings".
Even a driver that doesn't warn isn't necessarily useful, and I don't
want people to suddenly start seeing a lot of options for random ISA
drivers that simply aren't relevant, and never will be. Not even if
they compile cleanly.

               Linus

View attachment "patch.diff" of type "text/plain" (1926 bytes)