the drm tree merge process...
krh asked on IRC and I decided I may as well post this for others who may or may not be interested in how the drm patches go from someones brain into the Linus kernel tree.
We have a tree on freedesktop.org called the DRM git tree[1], this is the central repo for the Linux and BSD ports of the DRM, it contains a shared-core, linux-core and bsd-core directories.
shared-core contains only device driver code for supported gpus that is shared between OSes.
then the
$os-core contains the glue to bind that device driver into the OS of choice.
Now this tree isn't in the same format as a standard Linux kernel tree which has
linux-version/drivers/char/drm
and that contains a combined tree of shared-core, linux-core.
Also the DRM git tree contains backwards compatibility code that allows building against kernels back into the 2.6 era (possibly to 2.6.9 or so..., this breaks every so often...), via a series of hacks in drm_compat.[ch] and version checks, before this code goes into the kernel this stuff has to be removed along with checks for features that aren't support on the bsd side in the shared code..
So the kernel merge process work like this: I have a git clone of Linus's tree[2] with a drm-patches and drm-mm branches, the drm-mm branch gets pulled into Andrew Morton's -mm tree regularly and drm-patches is usually setup during the 2.6 merge windows (2 weeks after a major release) to what was in drm-mm on the previous cycle, and gets pulled into Linus's tree.
So I basically monitor the DRM git tree and any patches that are minor fixes or driver functionality upgrades normally soon after enter my merge queue for drm-mm, I usually port patches over using git-format-patch, or xemacs ediff is also useful, I find interacting with the patches usually makes be read them a bit more carefully than some automated system. I also clean up nasty whitespace and kernel coding violations on patches and the DRM git tree quite regularly...
However with some things I adopt a wait and see attitude to see how well tested they are after sitting in the drm git tree for a while, these patches consist of things I'm not comfortable merging yet or stuff I believe may cause regressions... (examples are the AGP buffer ownership check code, which I've discovered breaks miniglx for me :-)
For bigger things like the DRM memory manager we end up with a problem, the i915 driver is currently blocked on the DRM memory manager, the memory manager is a large complex piece of code and although it was developed to a functional level in the DRM git tree and the Xorg drivers support it, it is not yet ready for merging into the mainline kernel, firstly due to a lack of interaction with memory limits which could be quite insecure to ship and secondly because it needs a good bit more code review. In fact this code is so big a change it will most likely end up going via the Linux kernel mailing list instead of my git tree for merging. This creates a type of limbo where we have Xorg and Mesa drivers waiting for a kernel component to get merged.. this can be frustrating for distros but the rules for using code from the DRM git tree are:
1. the API isn't stable or secure. if you merge this and upgrade mesa or X.org later and it falls apart you keep both halves, I don't even want to see your name beside a ping on irc..
2. see rule 1.
I may post later on suggestions to change or improve the drm development process.
We have a tree on freedesktop.org called the DRM git tree[1], this is the central repo for the Linux and BSD ports of the DRM, it contains a shared-core, linux-core and bsd-core directories.
shared-core contains only device driver code for supported gpus that is shared between OSes.
then the
$os-core contains the glue to bind that device driver into the OS of choice.
Now this tree isn't in the same format as a standard Linux kernel tree which has
linux-version/drivers/char/drm
and that contains a combined tree of shared-core, linux-core.
Also the DRM git tree contains backwards compatibility code that allows building against kernels back into the 2.6 era (possibly to 2.6.9 or so..., this breaks every so often...), via a series of hacks in drm_compat.[ch] and version checks, before this code goes into the kernel this stuff has to be removed along with checks for features that aren't support on the bsd side in the shared code..
So the kernel merge process work like this: I have a git clone of Linus's tree[2] with a drm-patches and drm-mm branches, the drm-mm branch gets pulled into Andrew Morton's -mm tree regularly and drm-patches is usually setup during the 2.6 merge windows (2 weeks after a major release) to what was in drm-mm on the previous cycle, and gets pulled into Linus's tree.
So I basically monitor the DRM git tree and any patches that are minor fixes or driver functionality upgrades normally soon after enter my merge queue for drm-mm, I usually port patches over using git-format-patch, or xemacs ediff is also useful, I find interacting with the patches usually makes be read them a bit more carefully than some automated system. I also clean up nasty whitespace and kernel coding violations on patches and the DRM git tree quite regularly...
However with some things I adopt a wait and see attitude to see how well tested they are after sitting in the drm git tree for a while, these patches consist of things I'm not comfortable merging yet or stuff I believe may cause regressions... (examples are the AGP buffer ownership check code, which I've discovered breaks miniglx for me :-)
For bigger things like the DRM memory manager we end up with a problem, the i915 driver is currently blocked on the DRM memory manager, the memory manager is a large complex piece of code and although it was developed to a functional level in the DRM git tree and the Xorg drivers support it, it is not yet ready for merging into the mainline kernel, firstly due to a lack of interaction with memory limits which could be quite insecure to ship and secondly because it needs a good bit more code review. In fact this code is so big a change it will most likely end up going via the Linux kernel mailing list instead of my git tree for merging. This creates a type of limbo where we have Xorg and Mesa drivers waiting for a kernel component to get merged.. this can be frustrating for distros but the rules for using code from the DRM git tree are:
1. the API isn't stable or secure. if you merge this and upgrade mesa or X.org later and it falls apart you keep both halves, I don't even want to see your name beside a ping on irc..
2. see rule 1.
I may post later on suggestions to change or improve the drm development process.