lkml.org 
[lkml]   [2011]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Whitespace cleanups in drm/i915
On Thu, Sep 15, 2011 at 06:37:33PM -0700, Keith Packard wrote:
> I've got this nice patch from Akshay Joshi that removes almost all of
> the checkpatch.pl warnings from drm/i915. If I don't merge it now, it's
> going to go stale and be useless; if I merge it only to drm-intel-next,
> it will be the source of endless conflicts.
>
> However, it's a huge patch (yes, the code was rather sloppy), and
> doesn't exactly fit into the "critical patches only please" mode of the
> current stage of 3.1 development.
>
> I've checked the patch very carefully, using the obvious git diff -b to
> make sure it really doesn't touch anything but whitespace, but also
> using objdump -s to compare the output of the compiler. There were no
> differences found with git-diff -b. The only differences found by
> objdump are two whitespace changes in some debug output messages in
> intel_bios.c.
>
> I think I have three choices:
>
> 1) merge the patch and expect complaints from upstream
>
> 2) thank Akshay for his good intentions, discard the patch and hope
> that he feels motivated enough to do it all over again in time for
> the 3.2 merge window.
>
> 3) thank Akshay for his good intentions and leave the code as-is,
> forever to ease back-porting of fixes to older kernel versions.
>
> Frankly, if we're ever going to merge whitespace fixups, this would be a
> pretty darn good time; drm-intel-fixes and drm-intel-next are in-sync as
> I haven't started pulling 3.2 code into -next.

Well, I've just started to build up patches, so my current queue is tiny
;-)

Otoh massive whitespace changes always annoy when backporting fixes and
also when moving forward work-in-progress and old proof-of-concept
patches. If you think it's really worth it, go for it. Otherwise I think
strictly enforcing checkpatch compliance (and sparse-cleanliness, while
we're at it) going forward should get us there pretty quickly (we have
some code-churn after all). And then we could fix up the remaining code in
1-2 releases or so - by then that patch should only touch code that's in
maintaince mode for older hw, hopefully.
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48


\
 
 \ /
  Last update: 2011-09-16 16:33    [W:0.061 / U:6.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site