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

Message-ID: <20170207132353.rzeohwum2w6gehdy@phenom.ffwll.local>
Date:   Tue, 7 Feb 2017 14:23:53 +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:44:19PM +0100, Thierry Reding wrote:
> On Tue, Feb 07, 2017 at 12:21:28PM +0100, Daniel Vetter wrote:
> > 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.
> 
> Yeah, I'm aware of that list. I think it's a little problematic that
> it's in a wiki and far removed from where the actual work is happening.
> I think we should just take that list and add it as a TODO in
> drivers/gpu/drm, or alternatively keep it as part of the GPU
> documentation. That way we can more easily mark things as done or add
> new stuff as work gets done.
> 
> For cases like this I think we could just add new items as they are
> pointed out during review. For things that are already merged we can
> add items separately. Once the refactoring is done, the patch series
> can contain a final patch that simply removes the items again. I think
> that has much less potential to become out-dated than a separate wiki
> page.
> 
> FWIW, I'll volunteer to move the list to git if we decide to go ahead
> with that.

One upside of a wiki is that it's quicker to edit, if someone spots a
drive-by refactoring they might not bother with the formal requirements of
a full patch. Otoh, having it in-source-tree definitely has benefits, too.

If you do the conversion I'd vote for Documentation/gpu/TODO.rst, and
linking it into our documentation (maybe even cross-link from
introduction.rst under a "Getting Started" heading, as reasonable ramp-up
tasks after some checkpatch patches). I think that would help highlight it
a bit. And of course the wiki page needs to be removed and replaced with a
link to the new canonical thing (probably best to point at the source-file
in drm-tip.git, that should be the most up-to-date).

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch