internal screen concept

[Keith Packard]

On Wed, 23 Mar 2011 20:30:21 +1000, Dave Airlie <airlied at gmail.com> wrote:

> Yeah I was trying to get there in easier proveable steps.without doing
> a big change.

I was hoping that splitting the data out into the protocol screen would
be a pretty simple step; DDX bits using those fields would get caught
quickly, and could be easily audited as to whether they should be using
->protocol_screen->field or fixed in some other way.

I guess I'd like to see the planned layout of the data structures first
so we can see if that makes sense. Then fix up the code to match that,
and finally figure out if we want to just collapse all of the commits to
a single patch for master or try to do something prettier.

> Moving the information out into the protocolscreen was a step or two
> ahead, since I was going to have the audit the drivers for any abuse
> or information that we think is protocol but they think is theirs.

But, the compiler would catch all abuses, which makes the auditing a
whole lot easier (if more painful)?

> Yes that looks like where I'll end up once I get the bisectable/reviewable bits,
> the new process makes doing big changes like that nearly impossible as
> nobody will be able to review it.

There's nothing saying that what we merge to master has to be the same
sequence of patches as what you had review on; requiring bisect to work
will almost certainly wreck the readability of your patches.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110323/a64f31db/attachment.pgp>