Return-Path: <linux-kernel-owner+willy=40w.ods.org-S268005AbUI1Q47@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S268005AbUI1Q47 (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 28 Sep 2004 12:56:59 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268004AbUI1Q46
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 28 Sep 2004 12:56:58 -0400
Received: from e35.co.us.ibm.com ([32.97.110.133]:14220 "EHLO
	e35.co.us.ibm.com") by vger.kernel.org with ESMTP id S268005AbUI1Q4x
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 28 Sep 2004 12:56:53 -0400
Message-ID: <415997C6.1060802@us.ibm.com>
Date: Tue, 28 Sep 2004 09:56:38 -0700
From: Ian Romanick <idr@us.ibm.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Smirl <jonsmirl@gmail.com>
CC: dri-devel <dri-devel@lists.sourceforge.net>,
       Xserver development <xorg@freedesktop.org>,
       lkml <linux-kernel@vger.kernel.org>
Subject: Re: New DRM driver model - gets rid of DRM() macros!
References: <9e4733910409280854651581e2@mail.gmail.com>
In-Reply-To: <9e4733910409280854651581e2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2646
Lines: 58

Jon Smirl wrote:

I /should/ be able to look at the code changes sometime this week.  In 
the mean time, here are some initial comments...

> What are everyone's thoughts on this? There is no technical reason it
> can't be implemented on Linux 2.4/BSD, although I don't see any reason
> to do it for 2.4.

I'm of two minds about this.  On the one hand, I agree with you.  2.4 is 
in maintainence mode, and making a big change like this to the graphics 
driver system is outside that scope.  On the other hand, if the 2.4 and 
the 2.6 code bases diverge too much, bugs fixed on the 2.6 side are less 
likely to be fixed on the 2.4 side.  Moreover, with more divergence 
between the two, each gets less coverage.  I could really go either way 
on it.

> Any ideas on how to generate a unique identifier for the core? It
> probably should be regenerated by the Makefile whenever the core
> changes. Personalities would have to match the core identifier. This
> would stop people from loading binary modules that don't match the
> core.

I guess we'd want something like 'drm_core_version_<version number>'. 
Each layered driver would just have to reference the matching symbol. 
One neat thing about doing this is that we could theoretically make core 
modules that support multiple versions of the interal API and export a 
drm_core_version_* symbol for each.

I have only one problem with this type of setup.  If the user has a 
version mismatch, it's not trivially obvious why they aren't getting 
direct rendering.  There are already a number of ways a user can get 
"stuck" like this, and this adds another one.  It's not a new problem, 
but it is one that needs to be addressed.

> After sometime testing and fixing obvious problems I'll generate a
> patch for the 2.6 kernel and lkml.
> 
> [root@smirl linux-2.6]# lsmod | more
> Module                  Size  Used by
> tdfx                    2816  0
> sis                    10176  0
> mga                    56704  0
> i915                   16896  0
> via                    19428  0
> savage                  3840  0
> r128                   44672  0
> radeon                 70272  0
> drm                    59684  8 tdfx,sis,mga,i915,via,savage,r128,radeon

Anyone have a PCI card so that we can test actually using more than one 
at a time?  In the mean time, I think just having them all load at once 
and one of them work is good enough.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/