mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@linux.ie>
To: Dave Jones <davej@redhat.com>
Cc: Ian Romanick <idr@us.ibm.com>, Jon Smirl <jonsmirl@yahoo.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"DRI developer's list" <dri-devel@lists.sourceforge.net>
Subject: Re: DRM code reorganization
Date: Tue, 3 Aug 2004 01:06:44 +0100 (IST)	[thread overview]
Message-ID: <Pine.LNX.4.58.0408030048330.27728@skynet> (raw)
In-Reply-To: <20040802185746.GA12724@redhat.com>

>
> How does this differ from any other subsystem that supports
> cards with features that may not be present in another model ?
> Other subsystems have dealt with this problem without the need
> to introduce horrors like the abstractions in DRM.

The biggest issue I have with all the other subsystems that do this, is
the re-writing of basic driver code *for every driver*, everyone has a PCI
table, with a routine called my_driver_probe, and my_driver_init and
my_driver_exit and when you start a new driver you have to go all
cut-and-paste on its ass, someone changes and interface, you've got to go
change 20 files...

The DRM doesn't suffer from this, we've made huge changes to the DRM pci
probing code for *all* drivers (it's in the -mm tree if you want to look)
by changing one file, I'd hate to see similiar work being done to the fb
tree, you'd be cut-n-pasting and changing names of functions and it would
be horrible drudge work, the DRM isn't a maintainers paradise but if you
learn how it works it is an awful lot easier to maintain than similiar
subsystems...

> And among other horrors, crap like typedef's that magically change their
> type completely depending on which file they are #include'd into.
> Overuse of typedefs is one thing, but what goes on with stuff like
> DRIVER_BUF_PRIV_T is bordering on obscene.
>

this sort of stuff could probably be cleaned up, I'm not so sure this
re-org everyone is pushing for isn't going to lead to people wishing it
was the old way again :-)

> >From the view of many kernel developers, anything would be
> better than the trainwreck of wrappers/macros/preprocessor abuse
> that's there right now.  I'd put money on a lot more people being
> prepared to hack on DRM's kernel code if it were more readable.
>

If we start putting fb type functionality into it more people will start
coming towards it alright... it would be nice if it was a bit more
homely..

I'm sitting on the fence at the moment, as I'm not going to be able to
contribute the amount of time for a big re-write I'm willing to help out
with small changes and keep track of what patches go where....

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person


  parent reply	other threads:[~2004-08-03  0:07 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-02 15:53 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
2004-08-03 16:28             ` Ian Romanick
2004-08-03 16:49               ` Keith Whitwell
2004-08-03  0:06     ` Dave Airlie [this message]
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=Pine.LNX.4.58.0408030048330.27728@skynet \
    --to=airlied@linux.ie \
    --cc=davej@redhat.com \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=idr@us.ibm.com \
    --cc=jonsmirl@yahoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®