Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Dave Airlie <airlied <at> gmail.com>
Subject: DRM development process wiki page..
Newsgroups: gmane.comp.video.dri.devel
Date: Wednesday 27th August 2008 00:15:12 UTC (over 8 years ago)
Okay I've put some thoughts up at:
http://dri.freedesktop.org/wiki/DRMProcess

and I've pasted it in below this for discussion.

some other points:

a) People are pushing for a process change, we will have something
change, however this isn't a who shouts loudest competition, so more
than likely you'll end up compromising, deal with the fact that
nirvana for you may be hell for others.

b) BSD developers do exist now, giving out that they didn't exist in
the past or aren't adding features is pointless. Would you seriously
start developing features before
getting the code caught up?. So live with the fact that we should help
the BSD guys *if* its practical. So we shouldn't do anything major
that alienates their further development.
(personally I care little for BSD, the license or the OSes, however
I'm attempting to be some way fair).

c) We get testers from drm master, we get better testers using drm
master for features than a separate kernel tree. We get better
regression tests from getting stuff upstream. However upstreaming
stuff to Linus is not how to find regressions, it helps but its
suboptimal in that he will eventually ignore us if the regression rate
gets too high. So upstreaming is great for features like GEM, however
it would suck for something like vblank-rework. This appears to point
at, upstream is great if you touch one driver and exist in your own
world, however if you want interfaces that all drivers can use like
vbl-rework you need to work somewhere else or carry two interfaces
until everyone is ported.

So lets see if we can improve this for everyone...

Dave.


DRM Development Process (Proposed)

1. Master branch in Linux tree style with links for BSD etc.

2. Always compatible with current release Linux kernel + with
backwards compat *where* practical for older kernels. We should
probably limit the back compat  to like 6 kernel revisions or
something.

3. Macros for BSD compat to wrap Linux APIs. So we minimise the
nightmare of macros in driver code. no more DRM_ if they can be
avoided.

Patches

1. All patches to be sent to the mailing list with S-O-B, no patches
to be committed to master branch. Nothing goes upstream or into master
without Signed-off-by and maintainers Signed-off-by. 2. Do not mix
cleanup and developement ever. If you move a bunch of registers or
code into a separate file, do just that in one patch. 3. Backwards
compat patches in separate patches. So first patch should be
upstreamable, backwards compat patches should be in sequence.

Upstream first policy

This policy places a restriction on users of the drm, i.e. Mesa, DDX,
X server. No upstream release should include code that hasn't been
included in a Linux kernel release cycle. Upstream can use a
--enable-experimental-kernel-api type flag but default build should
never require any unreleased kernel/drm API to build or run. Distros
should not enable experimental APIs in releases, unless they are
willing to version their kernel and other components against each
other and deal with the fallout of API changes.

All userspace APIs need to be submitted to dri-devel and to the Linux
kernel list, also all patches which need exports or use new non-drm
kernel functionality should be reviewed by both lists.

Note: Do not expect because your code works that you won't have to
re-write it all for upstream. So upstream ideas early esp when you
interface to other kernel components.

Development

1. For large features or new drivers create a new branch in drm tree.
Stay in the branch, these branches will never ever get merged ever.
ever. When the developers feel the branch is suitable for upstream,
they need to create a clean set of patches following the rules above.
All API additions need to be reviewed and feedback taken on board. If
this involves another round of development, nuke the old branch and/or
start a new one from the patchset. Repeat cycle. When patches are
approved by anyone who cares they will get merged into the drm master
and into the upstream drm-next queue. Backwards compat patches will be
merged into drm master.

2. For minor cleanups and fixes, patches should be sent to dri-devel.

3. If a patch gets reverted from upstream kernel for a regression it
will also be reverted from the drm master branch.

4. If someone gets in the queue and you conflict you get to keep the mess.

DRM tree layout (plans)

1. Create drivers/gpu/drm/ exactly a mirror of current upstream. 2.
Add backwards compat cleanly on top of this tree with some patches. 3.
Add BSD compat in places that need it. 4. Migrate BSD to using the
upstream src files instead of the shared-core ones. 5. Evict all
non-upstream patches to branches, currently

    * - GEM - TTM - vblank-rework - i915 various bits, mmio oq interface.

Suggestions + help needed

In the future we may find we need a transitory drm-testing branch that
merges all the currently in development branches. This might help in
resolving conflicts before they happen. It would be nice to tinderbox
build the drm mainline and drm-testing against the last 6 released
kernels.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
--
 
CD: 4ms