On 6/14/07, Thomas Hellström <[EMAIL PROTECTED]> wrote: > 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.
True. And if we bump libdrm major version, we can drop the hash table and skip lists too. With DRI interface changes, I moved the hash table implementation into libGL, the only place it's used. Kristian ------------------------------------------------------------------------- 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
