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, 16 Feb 2017 16:54:45 +0000
From:   Emil Velikov <emil.l.velikov@...il.com>
To:     Tobias Jakobi <tjakobi@...h.uni-bielefeld.de>
Cc:     ML dri-devel <dri-devel@...ts.freedesktop.org>,
        Mark Rutland <mark.rutland@....com>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        devicetree <devicetree@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
        Chen-Yu Tsai <wens@...e.org>, Rob Herring <robh+dt@...nel.org>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        LAKML <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On 16 February 2017 at 12:43, Tobias Jakobi
<tjakobi@...h.uni-bielefeld.de> wrote:
> Hello,
>
> I was wondering about the following. Wasn't there some strict
> requirement about code going upstream, which also included that there
> was a full open-source driver stack for it?
>
> I don't see how this is the case for Mali, neither in the kernel, nor in
> userspace. I'm aware that the Mali kernel driver is open-source. But it
> is not upstream, maintained out of tree, and won't land upstream in its
> current form (no resemblence to a DRM driver at all). And let's not talk
> about the userspace part.
>
> So, why should this be here?
>
Have to agree with Tobias, here.

I can see the annoyance that Maxime and others have to go through to
their systems working.
At the same time, changing upstream kernel to suit out of tree
module(s) is not how things work. Right ?

Not to mention that the series adds stable ABI exclusively(?) used by
a module which does not seem to be in the process of getting merged.

Maxime, you're a great guy but I don't think this is suitable for
upstream... yet.

Regards,
Emil

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ