RFC: drm-misc for small drivers?

[Eric Anholt]

Daniel Vetter <daniel.vetter at ffwll.ch> writes:

> Hi all,
>
> We've discussed this a bit at LCA (with Dave and Eric), and it's
> probably best if I just summarize all the questions and opens and
> throw them out here for discussions:
>
> - When's a driver small enough for a shared tree, and when is a
> separate tree a good idea? i915 and amdgpu are definitely big, and
> there's definitely drivers who are really small and in-between it's
> unclear. Personally I think this is easy to do with a sliding scale,
> with using topic branches (we can do them in drm-misc easily) for
> bigger stuff, and if that's a common thing, split out the driver
> (thanks to the drm-tip integration tree there's not much of a
> difference in handling conflicts due to that anyway).

FWIW, I don't anticipate vc4 needing its own tree again if we can get
into a shared-maintainership one.  I think needing our own tree would
mean that there's something going wrong with the merge process, which we
should work hard to fix.

> - Should it be an entire separate tree for soc drivers? Problem here
> is that we lack a volunteer group (and imo it really should be a group
> to avoid the single-maintainer troubles) to run that. I think it's
> easier to proof the process first, and if we want a separate tree,
> split that out later on. This is the same thing we've done with
> drm-misc, first with a topic branch in drm-intel.git, then separate. I
> think it worked really well.

I'd rather not have an soc tree -- I don't think being soc drivers makes
us special.

> - Should we require review or at least acks for patches committed by
> the author? We have a bunch of drivers with effectively just 1 person
> working on it, where getting real review is hard. But otoh a few of
> those 1-person drivers will become popular, and then it's good to
> start with establishing peer-review early on. I also think that
> requiring peer-review is good to share best practices and knowledge
> between different people in our community, not just to make sure the
> code is correct. For all these reasons I'm leaning towards not making
> an exception for drivers, and requiring the same amount of review for
> them if they go in through drm-misc as for any other patch.

This is the only part I'm concerned about.  Would anyone review vc4
patches?  Voluntarily?  Actually thinking about the
functionality/structure of the code, not just style?

It sucks today that as part of the kernel process I send out patches
"for review", knowing that I won't ever get review, and I just have to
wait a while until I think people won't complain at me for sending a PR
too quickly.  But if the change is to just start blocking my patches on
review, I'm concerned I won't be able to get them in at all.

I think there's a middle ground, where you graduate to waiting for
review once you have multiple involved in that area of the code.  This
is what we do in Mesa -- vc4 and freedreno push directly, but on the
code we share (tgsi_to_nir, for example), we do review.

(This is also the point at which I'll offer: Any other ARM drivers that
want to do review exchange with me, let me know and I'll start paying
attention to your stuff)

> - Who's elligible? I think we could start small with a few volunteers
> and their drivers, and then anyone who's willing.

I volunteer as tribute.

(assuming a resolution for the above question)

> - Should we force new submissions to be managed in that shared treee?
> I think for initial submission a separate pull request for
> approval-by-Dave is good (but we could do that with topic branches
> too). And it's also way too early to tell, probably better to first
> figure out how well this goes.

I'd rather wait on changing policy for new drivers until we have tested
this change with existing drivers for a bit.  And for initial
submission, getting the ack from Dave will always seem mandatory to me.

> - CI, needed? It would be great, but we're not there yet :( Atm
> drm-misc just has a bunch of defconfigs that need to always compile,
> and that's it. Long term I definitely want more, but we're just not
> there yet. And it's a problem in general for drm-misc.

Keeping the defconfigs compiling is about as much CI as I have
currently, and I suspect that dim will actually improve how I do with
this (right now I'm relying on 0day a lot).  Supposedly kernel-ci.org
also boot-tests things, but I've never seen a breakage report so I'm
pretty skeptical of it.

> - dim scripts. Since we don't have a github flow where we can
> reasonably automate stuff on the server side we need something to
> automate on the client side. Thus far almost everyone seemed ok with
> the scripting that's used to drive drm-misc/intel/tip, but we can
> always improve things. And long term we can rework the approach
> however we want to really.

I haven't tested the scripts out yet, but browsing the docs
(https://cgit.freedesktop.org/drm-intel/tree/dim.rst?h=maintainer-tools
and
https://cgit.freedesktop.org/drm-intel/tree/drm-misc.rst?h=maintainer-tools)
they seem fine for me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170126/195bc7e7/attachment-0001.sig>