All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
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!
Date: Wed, 29 Sep 2004 13:37:59 +0100	[thread overview]
Message-ID: <20040929133759.A11891@infradead.org> (raw)
In-Reply-To: <9e4733910409280854651581e2@mail.gmail.com>; from jonsmirl@gmail.com on Tue, Sep 28, 2004 at 11:54:35AM -0400

On Tue, Sep 28, 2004 at 11:54:35AM -0400, Jon Smirl wrote:
> I've checked two new directories into DRM CVS for Linux 2.6 -
> linux-core, shared-core. This code implements a new model for DRM
> where DRM is split into a core piece and personality modules that
> share the core. The major reason for doing this is that it allows me
> to remove all of the DRM() macros; something that is causing lot's of
> complaints from the Linux kernel people.

I gave it a quick look and it looks great so far.

Some ideas that would be nice improvements still (not that some may be
inherited from the old drm code, I just looked at the CVS checkout):

 - once we have Alan's idea of the graphics core implemented drm_init()
   should go awaw
 - drm_probe (and it's call to drm_fill_in_dev) looks a little fishy,
   what about doing the full ->probe callback in each driver where it
   can do basic hw setup, dealing with pci and calls back into the drm
   core for minor number allocation and common structure allocations.
   This would get rid of the ->preinit and ->postinit hooks.
 - isn't drm_order just a copy of get_order()?
 - any chance to use proper kernel-doc comments instead of the bastdized
   and hard to read version you have currently?
 - the coding style is a little strange, like spurious whitespaces inside
   braces, maybe you could run it through scripts/Lindent
 - care to use linux/lists.h instead of opencoded lists, e.g. in
   dev->file_last/dev->file_first or dev->vmalist
 - drm_flush is a noop.  a NULL ->flush does the same thing, just easier
 - dito or ->poll
 - dito for ->read
 - why do you use DRM_COPY_FROM_USER_IOCTL in Linux-specific code?
 - drm__mem_info should be converted to fs/seq_file.c functions
 - dito for functions in drm_proc.c
 

  parent reply	other threads:[~2004-09-29 12:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-28 15:54 New DRM driver model - gets rid of DRM() macros! Jon Smirl
2004-09-28 16:56 ` Ian Romanick
2004-09-28 17:28   ` Jon Smirl
2004-09-28 19:35   ` Helge Hafting
2004-09-28 23:10 ` Dave Airlie
2004-09-29  1:27   ` Jon Smirl
2004-09-29  2:11     ` Dave Airlie
2004-09-29  5:25       ` Jon Smirl
2004-09-29 12:37 ` Christoph Hellwig [this message]
2004-09-29 11:59   ` Alan Cox
2004-09-29 13:16     ` Dave Airlie
2004-09-29 13:29   ` Keith Whitwell
2004-09-29 13:31     ` Christoph Hellwig
2004-09-29 13:35       ` Keith Whitwell
2004-09-29 14:12         ` Keith Whitwell
2004-09-29 14:16           ` Christoph Hellwig
2004-09-29 14:27             ` Keith Whitwell
2004-09-29 14:39               ` Keith Whitwell
2004-09-29 19:16                 ` Keith Packard
2004-09-30 18:10         ` Jon Smirl
2004-09-29 13:41   ` Dave Airlie
2004-10-01  5:15   ` Jon Smirl
2004-09-29 14:25 ` Keith Whitwell
2004-09-30  0:00   ` Eric Anholt
2004-09-29 21:52 ` Felix Kühling
2004-09-29 21:02   ` Alan Cox
2004-09-29 23:25   ` Jon Smirl
     [not found]     ` <20041006133714.GA26860@localdomain>
     [not found]       ` <9e47339104100609307307f8ea@mail.gmail.com>
     [not found]         ` <20041006211922.GA5167@localdomain>
2004-10-06 21:46           ` Code status (Was: New DRM driver model - gets rid of DRM() macros!) Ian Romanick

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=20040929133759.A11891@infradead.org \
    --to=hch@infradead.org \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=jonsmirl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xorg@freedesktop.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.