[Mesa-dev] [RFC PATCH 0/6] Refactor st_api and st/dri

[Chia-I Wu]

On Mon, Apr 26, 2010 at 6:54 PM, Keith Whitwell <keithw at vmware.com> wrote:
> On Sat, 2010-04-24 at 07:25 -0700, Jakob Bornecrantz wrote:
>> Hi Chia-I et all
>>
>> This Patch series does some minor refactoring in the st_api interface
>> and some major one to st/dri.
>>
>> The first patch drops the st_module struct from st_api. This is because it
>> was overlapping the st_api struct. Both represent the API. It also drops some
>> extra symbols and instead just exposes a single st_api_create_* function to
>> get the st_api struct from the state tracker.
>>
>> The following five patches refactor st/dri and removes some defines in favour
>> of hooks on dri_screen. And instead of allocating a separate struct for
>> st_manager and st_framebuffer makes them a base for dri_screen and
>> dri_drawable. And finally moves the code from dri_st_api.c into dri_screen.c
>> and dri_drawable.c.
>
> I've got some issues with the naming of these various state-tracker
> level components.
>
> First up, API is crazy - this is not an application programming
> interface.   Applications don't have a clue about this, it's buried deep
> inside the driver.
>
> Secondly, to label things st_XXX is probably misleading as it makes it
> appear as if these components are universal to state trackers, or that
> all state trackers must somehow use/conform to them.
>
> Can you think about what this code is really implementing & try to come
> up with a better set of names for these components?
Though not entirely true in current implementation, st_api.h is an interface
between a manager and its dlopen()ed modules.  Different modules provide
different Khronos-style rendering APIs.

Most of the interface is described using Gallium types (pipe_context,
pipe_texture, ...).  The manager and the modules are naturally implemented as
state trackers.  But the interface has nothing to do with a state tracker.  It
is somewhat more like dri_interface.h in that

  driDriverAPI   -> st_api_create_OpenGL
  __DriverAPIRec -> st_api
  __DRIscreen    -> st_manager

Maybe we can find a new namespace for the interface, and drop the "_iface"
suffix of st_framebuffer_iface and st_context_iface.  "struct st_api" describes
the interface of an API module.  It may be renamed to st_api_provider or
st_module.

-- 
olv at LunarG.com