From: Keith Whitwell <keith@tungstengraphics.com>
To: Ian Romanick <idr@us.ibm.com>
Cc: Dave Jones <davej@redhat.com>,
lkml <linux-kernel@vger.kernel.org>,
"DRI developer's list" <dri-devel@lists.sourceforge.net>
Subject: Re: DRM code reorganization
Date: Tue, 03 Aug 2004 08:52:26 +0100 [thread overview]
Message-ID: <410F443A.7050707@tungstengraphics.com> (raw)
In-Reply-To: <410ED3F7.7090809@us.ibm.com>
Ian Romanick wrote:
> I think this is the right place to start. A couple of these look easier
> to get rid of than others. __HAVE_MTRR and __HAVE_AGP are enabled in
> every driver except ffb. It should be easy enough to get rid of them.
> It looks like __HAVE_RELEASE, __HAVE_DMA_READY, __HAVE_DMA_FLUSH,
> __HAVE_DMA_QUIESCENT, and __HAVE_MULTIPLE_DMA_QUEUES (which looks broken
> anyway) should also be low-hanging fruit.
We've actually managed to do a fair bit of cleanup already - if you look at
the gamma driver, there's a lot of stuff in there which used to be shared but
ifdef'ed out between all the drivers. The __HAVE_MULTIPLE_DMA_QUEUES macro is
a remnant of this, but I think you'll break gamma when you try & remove it.
It used to be the case that 50% of the #if hoo-hah was just to try & keep the
gamma driver working. I don't know how true this is anymore, though.
> If we get that far, I think the next step would be to replace the
> DRIVER_* macros with a table of function pointers that would get passed
> around. Since I doubt any of those uses are performance critical, that
> should be fine.
>
> Then we can start looking at data structure refactoring.
>
>> > >If this kind of abuse wasn't so widespread, abstracting this code
>> > >out into shared sections and driver specific parts would be a lot
>> > >simpler. Sadly, this is the tip of the iceberg.
>> > > I think it comes down to the fact that the original DRM
>> developers > wanted templates. C doesn't have them, so they did the
>> "next best" thing.
>>
>> I vaguelly recall the code at one point not looking quite 'so bad',
>> it just grew and grew into this monster. I'm sure it was done originally
>> with the best of intentions, but it seems someone along the line got
>> a bit carried away.
>
>
> There was a point when a *lot* of the device-dependent code was still in
> the OS-dependent directories. This is how the i810 and i830 drivers
> still are. I think as more of the code got moved into the
> OS-independent directory, it got less pleasant to read.
Not a great deal changed as drivers got moved to shared/ -- things like
copy_from_user() got replaced by DRM_COPY_FROM_USER(), etc, but that's about
as far as it went. The template abstractions haven't really changed a great
deal with the introduction of freebsd support. If anything, code has been
simplified by moving the gamma-specific code out of the shared templates and
into gamma_* files.
Keith
next prev parent reply other threads:[~2004-08-03 7:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-02 15:53 DRM code reorganization Jon Smirl
2004-08-02 18:02 ` Ian Romanick
2004-08-02 18:27 ` Keith Whitwell
2004-08-02 18:57 ` Dave Jones
2004-08-02 18:16 ` Alan Cox
2004-08-02 20:11 ` Ian Romanick
2004-08-02 20:42 ` Jon Smirl
2004-08-02 21:09 ` Dave Jones
2004-08-02 21:51 ` Michel Dänzer
2004-08-02 23:09 ` Jon Smirl
2004-08-02 23:24 ` Alan Cox
2004-08-02 20:45 ` Dave Jones
2004-08-02 23:53 ` Ian Romanick
2004-08-03 7:52 ` Keith Whitwell [this message]
2004-08-03 16:28 ` Ian Romanick
2004-08-03 16:49 ` Keith Whitwell
2004-08-03 0:06 ` Dave Airlie
2004-08-03 6:13 ` Eric Anholt
2004-08-02 23:48 ` Dave Airlie
2004-08-02 23:26 ` 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=410F443A.7050707@tungstengraphics.com \
--to=keith@tungstengraphics.com \
--cc=davej@redhat.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=idr@us.ibm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.