linux-kernel - Re: [PATCH v3 2/7] drm/tinydrm: Add helper functions

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:   Tue, 7 Feb 2017 12:21:28 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Dave Airlie <airlied@...il.com>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v3 2/7] drm/tinydrm: Add helper functions

On Tue, Feb 07, 2017 at 12:11:28PM +0100, Thierry Reding wrote:
> On Tue, Feb 07, 2017 at 08:28:16AM +1000, Dave Airlie wrote:
> > >
> > > I definitely don't want that we don't attempt this. But brought from years
> > > of experience, I recommend to merge first (with pre-refactoring already
> > > applied, but helpers only extracted, not yet at the right spot), and then
> > > follow up with. Because on average, there's way too many trees with
> > > overloaded maintainers who maybe look at your patch once per kernel
> > > release cycle.
> > >
> > > If you know that backlight and spi isn't one of these areas (anything that
> > > goes through takashi/sound is a similar good experience for us on the i915
> > > side), then I guess we can try. But then Noralf has already written a few
> > > months worth of really great refactoring, and I'm seriously starting to
> > > feel guilty for volunteering him for all of this. Even though he seems to
> > > be really good at it, and seems to not mind, it's getting a bit silly.
> > > Given that I'd say up to Noralf.
> > >
> > > In short, there's always a balance.
> > 
> > I don't think we can make a rule for this, it will always depend on the
> > code. There is always going to be stuff we put in drm that should go
> > elsewhere, and stuff that is elsewhere that drm should use.
> > 
> > I think however if we do add stuff like this, someone should keep track
> > of them and try to make them get further into the kernel.
> 
> Yes, I think having some sort of TODO in drivers/gpu/drm could help
> track things that we know should eventually be moved out. It could serve
> as a list of janitorial tasks for newcomers that want to get their hands
> dirty and tackle relatively trivial tasks.

We have this list already, it's at: http://www.x.org/wiki/DRMJanitors/

I guess I should highlight it more, maybe even add it to the docs? Eric
just asked about it last week too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch