From: Jeff Hartmann <jhartmann@valinux.com>
To: unlisted-recipients:; (no To-header on input)@localhost.localdomain
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: 4.1.0 DRM (was Re: Linux 2.4.6-ac3)
Date: Mon, 16 Jul 2001 14:18:39 -0600 [thread overview]
Message-ID: <3B534C1F.8080100@valinux.com> (raw)
In-Reply-To: <E15M6jC-0005PK-00@the-village.bc.nu> <3B532BB7.1050300@valinux.com> <3B533578.A4B6C25F@damncats.org> <3B53413A.6060501@valinux.com> <995312089.987.8.camel@nomade>
Xavier Bestel wrote:
> 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.
>
> Xav
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.
-Jeff
next prev parent reply other threads:[~2001-07-16 20:20 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-14 17:36 Linux 2.4.6-ac3 Alan Cox
2001-07-14 20:01 ` Zilvinas Valinskas
2001-07-14 20:05 ` Alan Cox
2001-07-15 1:45 ` Gareth Hughes
2001-07-15 13:12 ` Alan Cox
2001-07-15 14:01 ` Gareth Hughes
2001-07-15 15:31 ` Alan Cox
2001-07-16 1:29 ` 4.1.0 DRM (was Re: Linux 2.4.6-ac3) Gareth Hughes
2001-07-16 1:51 ` Keith Owens
2001-07-16 2:07 ` Gareth Hughes
2001-07-16 11:23 ` John Cavan
2001-07-16 11:39 ` Alan Cox
2001-07-16 18:00 ` Jeff Hartmann
2001-07-16 18:12 ` Xavier Bestel
2001-07-16 18:32 ` Jeff Hartmann
2001-07-16 18:42 ` John Cavan
2001-07-16 19:32 ` Jeff Hartmann
2001-07-16 19:34 ` Xavier Bestel
2001-07-16 20:18 ` Jeff Hartmann [this message]
2001-07-17 2:37 ` Gareth Hughes
2001-07-17 8:31 ` Mike A. Harris
2001-07-16 19:49 ` John Cavan
2001-07-17 7:19 ` 4.1.0 DRM Mike A. Harris
2001-07-17 5:28 ` 4.1.0 DRM (was Re: Linux 2.4.6-ac3) Juan Quintela
2001-07-18 9:06 ` Gareth Hughes
2001-07-18 16:21 ` Juan Quintela
2001-07-18 13:30 ` Mike A. Harris
2001-07-17 13:19 ` Linux 2.4.6-ac3 Zdenek Kabelac
2001-07-15 1:31 ` Linux 2.4.6-ac3 - some unresolved Eyal Lebedinsky
2001-07-15 13:09 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B534C1F.8080100@valinux.com \
--to=jhartmann@valinux.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox