1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
# 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.
|
