On Mon, Dec 02, 2024 at 02:07:36PM +0200, Jani Nikula wrote:
> On Mon, 02 Dec 2024, Maxime Ripard <mripard@xxxxxxxxxx> wrote:
> > It's not about whether we have a problem or not: you introduce new
> > framework functions, you need to have kunit tests to check their
> > behaviour.
>
> I don't fundamentally disagree with that goal,
You don't really have to agree. You asked for my review, you have it.
> but it does seem like a pretty drastic policy change. I don't recall a
> discussion where we made that decision, nor can I find any
> documentation stating this. Or what exactly the requirement is; it's
> totally unclear to me.
There isn't, because there's no such policy, even though it's definitely
something I'd like. This situation is different though:
drm_connector_init is already a function that is being tested. It seems
natural to not dilute testing when adding new variant, disregarding what
the policy of the rest of the framework is.
> Had I been involved, I would've pointed out that while adding tests is
> good, it inevitably increases the friction of adding new stuff to drm
> core.
You also know what increases the friction of adding new stuff? Adding
new stuff. Or writing documentation. Or writing commit log. Or sending
emails / making pull requests. Or asking for cross-reviews. Or having an
open-source user-space requirement. It seems pretty arbitrary to draw
the line right where testing starts.
> It's super tempting for people to just get their jobs done. If doing
> the right thing adds yet another hurdle, we may see more stuff being
> added in drivers instead of drm core.
I really enjoy hidden threats. And it's not like i915 is a great example
there.
> (Case in point, we already hacked around the problem being solved here
> with commit d58f65df2dcb ("drm/i915/dp_mst: Fix connector initialization
> in intel_dp_add_mst_connector()"). We could've just dropped the ball
> right there.)
Case in point indeed.
Maxime
Attachment:
signature.asc
Description: PGP signature
