On Mon, 02 Dec 2024, Maxime Ripard <mripard@xxxxxxxxxx> wrote: > 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. "You do X, you need do have Y" coming from a maintainer sure sounded like hard rules. I was surprised. >> 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. None were implied. That's your interpretation of what I honestly think is a plausible outcome. I try to push people towards contributing to drm core instead of drivers, and it's not always easy as it is. It's just a guess, but I'll bet the majority of drm contributors have never run kunit tests themselves. > And it's not like i915 is a great example there. Sincerely, is this the level of discussion we really want to have? BR, Jani. -- Jani Nikula, Intel
