Re: [PATCH 1/1] Adapt on_each_cpu

[Jesse B. <jb...@vi...>]

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...