On Wed, 2010-02-03 at 07:12 -0800, Jakob Bornecrantz wrote: > Also the removal of some of the inlines seems a bit to harsh as well, > the pipe_buffer_{unmap|map} inlines for instance holds a bit of > semantics in them. In short about this and the p_atomic functions, I > view them as apart of the interface just as much as pipe_context. Is > there a particularly reason for removing the inlines? Portability or > just general dislike of them?
I'm not really sure that I agree with this statement. The inline functions do not define the interface, they *respect* the interface. They are convenience/utility routines and really belong with all our other convenience/utility routines in gallium/auxiliary. There is nothing magical about those inlines that modify, restrict, or enable the users of the interface. Anything done by the inline can be done directly with the pipe_screen/pipe_context structures and there is nothing which makes using those inlines mandatory. Historically we had a lot of helpers in gallium/include, which have been incrementally moved out to gallium/auxiliary. Keith ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev