On Thu, Jul 31, 2008 at 10:53 PM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > On Thursday, July 31, 2008 6:40 pm Dave Airlie wrote: >> > Well, if the overhead of merging upstream is a concern, then how about >> > not worrying about bc at all and let people who want to back port deal >> > with it? Oh, and what about just keeping the drm drivers in a linux >> > kernel tree? That'll make upstream merging even easier yet... >> >> The less crap I have to remove from the diffs the better, I have a script >> and it removes stuff mostly fine, maybe someone should actually bring this >> idea up on the list with a proper plan for how to deal with >> >> a) BSD
Jesse, thanks for writing this up more coherently and politely than I could ever do. It's easy for me to say "that's what I had in mind" now that you've written it all down, that is pretty much the case. > I'd like to hear Robert's concerns here, but I've been working with some of > the BSD folks lately, and it seems like the main concerns are: > 1) making it easy for contributors to identify which portions of code are > shared > 2) licensing > Since both the BSDs and Linux effectively copy code out of the DRM repo and > into their respective kernel trees at this point, having the actual repo > based on one of them shouldn't be an issue as long as both 1 and 2 are > handled. The remaining compat macros could probably just be wrapped in some > sort of Linux equivalent (DRM_SPINUNLOCK->spin_unlock, what's the > difference?), or we could annotate things for the BSD guys to run scripts > over. As it stands, they still have to go over things by hand anyway... > > I think both of the above can be addressed fairly easily no matter which tree > we choose (obviously I'd like to see a Linux kernel based tree :), by > appropriately commenting shared files and making sure contributors understand > the licensing implications of their contributions (maybe a drivers/gpu > specific README.licensing or somesuch). Agree on all this. >> b) backwards compat for using updated DRM drivers on older kernels. > > Personally, I only use the existing DRM repo on old kernels because that's how > it's structured. It's actually more work for me to download & build a recent > kernel, then update & build the DRM drivers against it that it is to simply > update the DRM drivers and build against my current kernel (or just updating > a theoretical DRM kernel tree & building for that matter). > > So really I don't think keeping compat *in-tree* for old kernels gives us > extra testing. It's really no harder or easier to do the same thing with a > full kernel tree, just different. IMO anyway. Yeah, we could keep the BC code around if we moved the drivers in-tree, and that would let you compile the drivers against an older kernel using something like: make -C /lib/modules/$(uname -r)/build M=$PWD from the drivers/gpu/drm directory. >> If enough DRI developers are willing to take the stand that they don't >> care about a or b, then I'm willing to change the development model. So >> far I've hear grumbles and mumbling, where I expect coherent proposal or >> gtfo. >> >> The biggest thing I have against this is that it cuts our testing base >> down, we have a small testing base already, cutting it further jsut to >> benefit some developers who are frustrated isn't really a gain. Testing is part of the problem with the current set up. What are people actually testing when they run drm.git drivers with their distro kernel? Right now drm.git has the vblank bits, the ttm bits and various smaller stuff. Much of this stuff interacts in non-trivial ways, such as the intel irq handler, and hand picking changes, editing the patch to apply upstream, pretty much invalidates any testing done on the drm.git repo. So the closer the drm repo can be to upstream, the more effective the testing will be. To be fair, this isn't all because of the out-of-tree drm.git setup. We've failed, as a community, to get a lot of stuff upstream (vblank stuff took a long time to get ready, there's the memory manager shoot out etc), and as a result, the gap between drm.git and upstream has grown hard to manage. > Well, I think there are other potential gains. What are the major problems > with the current scheme, maybe we can address those without affecting the > issues you mentioned above? In my view, the big issues are: > 1) we don't really know what's going upstream and when (there's not > a "standard" Linux s-o-b process for DRM) until it happens > 2) DRM changelogs are basically useless since they get destroyed when going > upstream, which means many of our commit messages are unhelpful, to say > the least (look at most of modesetting-101 for lolz) > 3) having a "different" development process like this increases the barrier > to entry for potential developers (this is mostly speculative since we > don't know how many potential developers we have, but I think it's still > a valid point) > 4) Linux moves fast and I think having an out-of-tree project means we're > often out of date, see the recent on_each_cpu or suspend/resume API > changes for examples Another benefit from having the DRM repo structured as linux kernel tree is that changes from upstream linux development (janitorial stuff, tree-wide api changes) only takes a 'git merge' to carry over to the DRM tree. In other words, making it easier to push changes upstream works both ways, it also becomes easier to pull down changes from upstream that touches the DRM subystem. Hm, I guess that's what your saying in 4). So, I very much agree with your proposal and don't feel I can add much, except to point out that a migration to in-tree drm development doesn't need to be a big and painful process. Basically, we just decide to do it, and designate a kernel tree on freedesktop.org that we work from and start with the current state of upstream drm. There will be some work in moving things over from drm.git to the kernel tree, but we were going to do that *anyway* as part of getting it upstream. What will be different is that Dave won't have to do all that work, we can split it up between us and all Dave will need to do is to merge the branch and push it to Linus. This is of course what Eric is already doing with GEM in people.fd.o/~anholt/linux-2.6, and that would be a great way to get the vblank rework upstream too. cheers, Kristian ------------------------------------------------------------------------- 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=/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
