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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
