Code review comment for lp://staging/~kdub/mir/gbm-ext-v2
Revision history for this message
| Daniel van Vugt (vanvugt) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
5466644
demo site
(Get the code!)
(6) is also unconvincing. We shouldn't be designing new APIs that accept MirBuffer* yet implicitly only work on GBM buffers. This would be resolved by forcing the client side to provide gbm_bo. If the extension is for "GBM" then it's perfectly reasonable that users of it will link to GBM and be using gbm.h. If however you can get away with abstracting out gbm.h entirely as you have, then in theory we can get away from calling anything in it "GBM". It should therefore either be a more abstract interface (not mention "GBM" at all) or less abstract interface and use gbm_bo directly.
I feel this GBM v2 extension will soon need to be deprecated and replaced by a v3. However I also don't have sufficient interest in this area of code to stand in the way. Rapid deprecation and redesigns might be the fastest way forward. If any reviewer disagrees with my comments then go ahead and land it...