> On 16 Jul 2001 13:32:10 -0600, Jeff Hartmann wrote:
>> No, because the 2D ddx module is the one doing all the versioning. It
>> doesn't tell the kernel its version number etc., but the ddx module gets
>> the version from the kernel, and fails if its the wrong one. If the
>> kernel was the one doing the checking, then your suggestiong would be a
>> nice way of handling it.
> Well ... you're gonna change the API anyway, so you could add that in
> the protocol.
> Still, I'm a bit disappointed with this ever-changing API. A bit
> un-linux if you ask me.
You have to remember this isn't an API that users program to, it is an
API that a specific driver uses. Each driver is different, and has a
different API (at least a subset of it.) The cards are so different
that they can't have the same interfaces and remain competitive. Each
3D client side driver packages up state and vertex data in a form that
only that video card can understand. Each new drm kernel driver
requires a new device specific portion of the API.
Basically it boils down to this:
If we want to be secure, we have to have an interface which can remain
competitive with insecure drivers. To accomplish this we have to
tightly couple our 3D client side drivers with our drm kernel modules.
We are bound to develop more efficent ways of doing this over time, and
the interface will have to change under most circumstances.
If we were NOT secure we could probably have a pretty static API (send
this area of dma commands to the card), however this is unacceptable.
Especially since most graphics cards can DMA to ANYWHERE in system
memory. Our DRI drivers must be secure, thus we introduce alot of
issues to 3D driver writing, one of which is API incompatibility.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/