Message-ID: <20260122-bold-sticky-wapiti-1dffa2@houat>
Date: Thu, 22 Jan 2026 15:39:33 +0100
From: Maxime Ripard <mripard@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Uwe Kleine-König <u.kleine-koenig@...libre.com>, 
	linux-pwm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Michal Wilczynski <m.wilczynski@...sung.com>, Richard Genoud <richard.genoud@...tlin.com>
Subject: Re: [GIT PULL] pwm: Two fixes and a maintainer update

Hi,

Going a bit off topic here, sorry.

On Tue, Jan 20, 2026 at 10:11:27AM -0800, Linus Torvalds wrote:
> On Tue, 20 Jan 2026 at 01:32, Uwe Kleine-König
> <u.kleine-koenig@...libre.com> wrote:
> >
> >    You might argue that this is an ABI change [..]
> 
> Pretty much any change can be an ABI change - even totally new
> interfaces change behavior in that something that didn't use to do
> anything now does something.
> 
> And we've actually very much have had things like that happen too,
> when broken user space did something odd, and adding a completely new
> file in /proc (or something like that) just broke broken user space.
> 
> And any bugfix that changes visible behavior is also an "ABI change",
> and so there is no practical meaning to the whole otion.
> 
> So I absolutely detest the whole notion of "ABI changes". It's a
> meaningless concept, and I hate it with a passion, because it then
> results in the "opposite" situation where some projects seem to think
> that ABI changes are perfectly fine as long as they go along with
> version number changes.
> 
> The Linux rule for regressions is basically based on the philosophical
> question of "If a tree falls in the forest, and nobody is around to
> hear it, does it make a sound?".
> 
> So the only thing that matters is if something breaks user-*conscious* behavior.
> 
> And when that happens, the distinction between "bug fix" and "new
> feature" and "ABI change" matters not one whit, and the change needs
> to be done differently.
> 
> Anyway, I agree that the whole "return proper -EFAULT on user copy
> failures" is clearly the right thing to do, and I do not disagree with
> the patch at all.
> 
> I just wanted to point out that the argument about whether it's an ABI
> change or not is irrelevant. If it turns out that some program - not a
> test script, but something with relevance to conscious user
> expectations - depended on the old broken behavior, then it needs to
> be done some other way.
> 
> So whether somebody "argues" that the change is an ABI change or not
> is simply not relevant to anything.
> 
> Obviously some changes are more likely to be user-visible than others,
> so people should take that into account in how careful you need to be
> about a patch.

Where do we draw the line then, if there's any?

I have a particular example in mind with v4l2. With some drivers, and
because pixel order naming is confusing and inconsistent in the media
industry as a whole, we ended up with drivers capturing framebuffers
with the wrong pixel order (blue and red inverted) compared to
documented order for the format they were requesting. And rejecting the
format with the "right" order.

We've been tip-toeing about this to fix it in order to avoid any
regression in some tools.

Should we just consider those drivers "wrong", treat it as a bugfix, and
expect userspace applications to request the format they actually rely
on? Or should we continue what we've tried to do and try to support the
right format, and the old format for backward compatibility?

Thanks!
Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)

Powered by blists - more mailing lists