[Intel-gfx] [PATCH 2/4] drm/i915: encoder/connector internal structure rework (v5)

[Zhenyu Wang]

On 2010.03.24 14:03:16 -0700, Eric Anholt wrote:
> 
> This is not acceptable.  The problem in this series is still that step 1
> is:
> a) s/intel_output/intel_encoder/
> b) also change a bunch of code.

'intel_output' is replaced by 'intel_encoder' and 'intel_connector',
which I hope should be the clean way to represent our display hw in drm
KMS framework. As I tried to remove it completely, and it's used in all
places e.g all outputs driver code, I have to make them in one place for
bisectable. Each output driver's original 'intel_output' becomes 'intel_encoder' 
part and 'intel_connector' part. 

> 
> When someone bisects down to this, they will probably just give up.
> Doing just the sed is:
> 
> 11 files changed, 663 insertions(+), 663 deletions(-)
> 
> Why should someone have to look through 872 lines of code to find the
> bug in the 209 lines of non-automated patch?  And why should I have to
> review all that sed job even before a bug's been found?

It's not a sed job to me, I have to check the functional meaning for the
change to apply to encoder or connector, to be sure in the new representation
they still do the right reference.

Yeah, maybe the first restructure patch for the different output presentation
is mixed with structure name change and some semantic change too. But the whole
point is to have no regression compared to origin driver, and just convert the
structures. Or do you have suggestion on a better way?

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100325/1fc1ee9f/attachment.sig>