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
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).
> 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.
And if there *were* a regular, Linux-style DRM tree, it would be easier to
pull in changes from other subsystem trees for testing purposes (e.g. the PCI
read base stuff, or the shmem stuff assuming Al has a tree somewhere with it,
or the suspend/resume API stuff or what have you).
> If someone writes a coherent proposal I'm all ears, all I'm hearing is
> "other kernel subsystems", but on my review 2 other kernel subsystem have
> a major userspace part to worry about, alsa and v4l. They both developed
> in out-of-tree with backwards compat code.
Unfortunately, I don't think either of those code bases do things particularly
well either. Upstream changes are often invisible to actual users for much
longer than they should be, and the conflation of the userspace code with the
external repo means that compatibility is actually *harder* to maintain, not
easier, since interfaces aren't separated enough to force people to think
about them. Or in the case of v4l, things just progress really slowly until
the next rewrite.
To be fair, I think we haven't been horrible about this in the DRM (yet).
Generally old stuff still works on new kernels, which is important. But we
also don't have a userspace component nearly as large as the ALSA guys for
example; the number of ioctls we have is still pretty manageable.
> 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.
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
Ultimately, I'm used to the current scheme, so I'm not going to become 100x
more productive if we move to a more common Linux-style model. But I think
it would add some visibility to things for those not in the DRM/DRI cabal,
and make interacting with the rest of the kernel a bit easier.
Jesse
P.S. I hope I don't sound too ungrateful here. Honestly I don't know how you
manage to push stuff from the DRM repo into upstream with any regularity and
keep your sanity...
-------------------------------------------------------------------------
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
