Dave Airlie wrote: >> > > cheers, >> > > Kristian >> > > >> > Kristian, >> > This is OK with me. It will add an extra malloc / free for every >> buffer >> > object creation / destruction, >> > but will make it easier to maintain in the future, (and we can get rid >> > of the padding for future expansion). >> >> Exactly, I took out the pad fields in the patch. I think it's a >> reasonable tradeoff, since we have a library abstraction barrier here >> and the objects aren't tiny to begin with. > > I can't see any problems with this, who has the time to do it? I'm up > the walls with real life.. > Same here. However, we don't strictly need to change the libdrm user-space interface right now.
If we focus on getting the kernel TTM code in shape at this point, we can change libdrm at a later point, bumping its major version. The dl code should automatically load the correct version so we won't really have to bother about the next big incompatibility. That would mean we can merge the ttm-cleanup branch after a ioctl arg size check. I'll see if I can do that tonight. /Thomas > Dave. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
