linux-kernel - Re: [git pull] drm for v4.11

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:   Thu, 23 Feb 2017 17:56:28 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Dave Airlie <airlied@...il.com>,
        Noralf Trønnes <noralf@...nnes.org>,
        Thierry Reding <treding@...dia.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>
Cc:     dri-devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm for v4.11 - main pull request

On Thu, Feb 23, 2017 at 5:44 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> AND WHY THE HELL WAS THIS UTTER SHITE SENT TO ME IF IT WAS COMMITTED YESTERDAY?

.. and a slightly less annoying piece of crap in this pull request:
that "PRIME_NUMBERS" config thing is utter garbage too.

Why would you ask a user about it? The only valid use is for a kernel
module that needs it to "select" it, so there's no point in asking the
user if they want it.

We don't want to make the kernel config phase any worse than it
already is (and it's bad). Asking people idiotic and pointless
questions is simply not ok.

Christ. I dislike this pull request intensely, and I haven't even
gotten to the point where I can even _test_ it yet.

I'm very close to just saying "this is complete bullshit" and not pull
any DRM crap this merge window.

Honestly, if I find anything else, that's what I'll do. I might do it
even without finding anything elze.

And _reghardless_ of what happens this merge window, I will instate a
hard rule that the DRM code needs to be in linux-next *before* the
merge window opens.  No last-minute crap. No shit that hasn't even
been build-tested.

Because I am _never_ going to accept this kind of crap in the future.

If I find broken stuff like this from just a cursory examination and
build test, things are seriously wrong.

I think I'm also going to require the DRM pull requests to be split
up, because as it is now, I'm in the situation that I have to accept
all or nothing. Which is not good, when the "all" stuff is of this
dubious quality.

And if the DRM "maintenance" is about sending me random half-arsed
crap in one big pull, I'm just not willing to deal with it. This is
like the crazy ARM tree used to be.

Guys, this needs to be fixed.

               Linus