No subject

"The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path."

So I considered myself involved in the development of the patch (given our
messages exchanged in pvt). Anyway, this is just nitpick...

 
> > oops, I forgot to mention that you can remove the entire function wrapping
> > there, Jamey. Just remove VGAarbiterCreateGC entirely.
> 
> That's why I want this patch applied, but I believe the rest of the
> patches on my for-1.10 branch are needed before it's safe to entirely
> delete this function, and I haven't sent those out for review yet.
> 
> Currently, as far as I can tell, the VGA arbiter needs a wrapper
> around ValidateGC, just so that it can unwrap the ops on the way down
> the ValidateGC chain, in case some other ValidateGC wrapper changes
> the ops pointer. And the current way to get a wrapper around
> ValidateGC is to hook the funcs chain from CreateGC.
> 
> When my later patches impose the rule that GC funcs must not modify
> the GC ops, then it's safe to delete an awful lot of code, and even
> more when I then move the funcs and ops chains to the ScreenRec.

All right.

 
> > Also, if all GC operations don't touch the hw at all for all kind of accel,
> > then we can extend this patch for the other functions there.
> 
> I don't think anybody's GC funcs touch the hardware, which is good
> since the VGA arbiter is already not taking the arbitration lock
> around those. But hopefully somebody's GC ops are touching the
> hardware or else the whole ops abstraction is pointless.
> 
> With those clarifications, are you satisfied with this patch?

Yes! :)
             Tiago