|| ||Dave Airlie <email@example.com>|
|| ||New proposed DRM interface design|
|| ||Sat, 4 Sep 2004 01:12:16 +0100 (IST)|
Okay I've had some thoughts about the DRM interfaces and did some code
hacking (drmlib-0-0-1 branch on DRM CVS , very incomplete)
Below is my proposal for an interface that does introduce a major new
binary interface (the biggest issue with a straight core/personality split
for DRI developers, we have enough binary interfaces in our lives)...
Any comments are appreciated, the document is also available at:
This documents a proposed new design for the DRM internal kernel interfaces.
The current DRM suffers from a number of issues with multiple drivers in
the same kernel (the mess that is the drm_stub.h and parts of drm_drv.h)
along with the DRM() macros show this up. This design tries to address
this issue without introducing any major new binary interface.
I propose a 3 way code split-
This is slightly along the lines of the fb where the core is fbmem + co,
the library is the cfb* object and the driver is the graphics chipset
What I would like to do for the DRM is not as extreme as the fb approach.
I propose the following type split:
DRM core - just the stub registration procedure and handling any
shared resources like the device major number, and perhaps parts of sysfs
and class code. This interface gets set in stone as quickly as possible
and is as minimal as can be, (Jon Smirls dyn-minor patch will help a fair
bit also). All the core does is allow DRMs to register and de-register in
a nice easy fashion and not interfere with each other. This drmcore.o can
either be linked into the kernel (ala the fb core) or a module, but in
theory it should only really be shipped with the kernel - (for compat
reasons the DRM tree will ship it for older systems).
DRM library - this contains all the non-card specific code, AGP
interface, buffers interface, memory allocation, context handling etc.
This is mostly stuff that is in templated header files now moved into C
files along the lines of what I've done in the drmlib-0-0-1-branch. This
file gets linked into each drm module, if you build two drivers into the
kernel it gets shared automatically as far as I can see, if you build as
modules they both end up with the code, for the DRM the single card is the
primary case so I don't mind losing some resources for having different
cards in a machine.
DRM driver - the current driver files converted to the new
interfaces, I don't mind retaining some of the templating work, I like the
fact that we don't have 20 implementations of the drm probe or PCI tables
or anything like that, so I think some small uses of DRM() may still be
acceptable from a maintenance point of view.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/