RE: [Dri-devel] Restoring DRM Library Device Independence

[Jeff H. <jha...@ad...>]

-----Original Message-----
From: dri...@li...
[mailto:dri...@li...]On Behalf Of Kevin E
Martin
Sent: Thursday, March 28, 2002 8:25 AM
To: David Dawes
Cc: dri-devel
Subject: Re: [Dri-devel] Restoring DRM Library Device Independence


> I'm losing track of what the goal was with the changes.  If it was
> to remove hw-specifics from the libdrm.a module, then I think Jeff's
> idea of pushing them into a separate HW-specific module is worth looking
at.
> By doing this, it might even be feasible to make libdrm.a part of the
> (built-in) OS-support layer.

I believe seperating out the hw dependancies to make binary releases easier
is the reasoning for the change.

I do think that perhaps making libdrm.a part of the built-in OS-support
layer is an excellent idea.  Even though it is a small change, this might
give more people a reason to start porting to the drm to other OS'es.

>
> Stepping back a bit, the current model puts different types of
> dependencies in different places.  The XFree86 video driver module
> contains HW dependencies, but should have no OS dependencies.  The
libdrm.a
> module contains both HW and OS dependencies.  I guess the aim is to
> separate that into the HW-dependent and HW-independent pieces?

Yes.

>
> One problem I had with simply changing the libdrm.a interfaces is
> that it doesn't succeed in making that separation.  Something in
> libdrm.a still needs to know how to translate a HW-specific command
> into whatever is appropriate for the OS.  I.e, there's nothing
> conceptually different between drmRadeonCPStop(args) and
> drmCOMMAND(RADEON_CP_STOP, args), unless the token RADEON_CP_STOP
> can be passed transparently to the HW+OS specific component that
> will actually do the requested operation.

It could be done, but its ugly and it makes too many assumptions about the
underlying OS.  Because of these assumptions I don't like an implementation
of a drmCOMMAND (or ioctl, etc.)  It just doesn't fit in an OS independant
interface.

>
> With Jeff's suggestion there would be several components:
>
>   video driver module    (HW specific, OS independent)
>   core libdrm module     (HW independent, OS specific, so part of core
server?)
>   HW libdrm module       (HW specific, OS specific)
>
> The question this raises is what do we gain from this?  What would
> actually be in the core libdrm module -- is there enough there to
> justify separating out the HW-specific parts?
>
>

The core libdrm module would have all the OS dependant parts that are HW
independant.  This is actually the bulk of what libdrm contains.  The
hardware specific portion is small, but can be very different for each card.

We can actually then ship whole scale replacements to just a driver suite
without having to change out other modules that ship with an OS
distribution.  This allows an upgraded driver suite to be installed over an
Xserver installation without breaking other drivers.  If each driver suite
ships with a different libdrm.a we start having conflicts really quick.
Binary releases become alot easier with this seperation.  People like Redhat
might start shipping driver upgrades only, rather then requiring a user with
a broken driver to download a new Xserver.  That is a very good thing for
the end user in my opinion.  In the current model, this sort of packaging is
prohibited.

-Jeff