Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Peter Korsgaard <peter@korsgaard.com>
To:     Jean Delvare <jdelvare@suse.com>
Cc:     linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Revert "firmware: dmi_scan: Use lowercase letters for UUID"
References: <20181205211351.5309-1-peter@korsgaard.com>
        <1544086444.5492.1.camel@suse.com> <87a7ljyppx.fsf@dell.be.48ers.dk>
        <1544092087.5492.3.camel@suse.com> <878t1264lf.fsf@dell.be.48ers.dk>
        <87efaotgi1.fsf@dell.be.48ers.dk> <1544536167.5269.7.camel@suse.com>
Date:   Tue, 11 Dec 2018 15:36:51 +0100
In-Reply-To: <1544536167.5269.7.camel@suse.com> (Jean Delvare's message of
        "Tue, 11 Dec 2018 14:49:27 +0100")
Message-ID: <87a7lct9j0.fsf@dell.be.48ers.dk>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

>>>>> "Jean" == Jean Delvare <jdelvare@suse.com> writes:

 > On Tue, 2018-12-11 at 13:06 +0100, Peter Korsgaard wrote:
 >> > > > > > "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:
 >> 
 >> Hi Jean,
 >> 
 >> >> Look, you can imagine that I was perfectly aware of what I was doing
 >> >> when I made that change, and that I pondered the decision carefully at
 >> >> that time. And my decision was that the change should be made. As far
 >> >> as I'm concerned, this ship has sailed already, sorry.
 >> 
 >> > Sorry, what is the perceived risk of reverting this change? Just the
 >> > minor inconsistency between the dmidecode and sysfs output? As stated
 >> > above, the RFC requires conforming parsers to handle upper case as well.
 >> 
 >> I would appreciate if you could explain what risk you see from reverting
 >> this change?

 > The exact same risk that you are complaining about, for a different
 > pair of kernel versions. You cannot at the same time argue that the
 > change should not have been done back then, and ask for same change to
 > be done again now.

With that kind of catch-22 logic, no regressions can ever be fixed. This
change was part of 4.17, released 6 months ago, whereas the previous
behaviour has existed for an order of magnitude longer.

While it is true that there is a chance that somebody may rely on the
new behaviour, it is likely to be significantly smaller than the chance
that someone relied on the previous behaviour (E.G. the breakage in my
software is proof of at least one such instance). Given that 4.19 has
only recently become a LTS kernel and distibutions with 4.17+ are only
getting released now (Fedora 29, Ubuntu 18.10) chances are that more
people will be affected in the future.

But you are right, we should do the revert as soon as possible, before
people start relying on this new behaviour.

I can extend the commit message with a reference to RFC4122 if you
prefer that over my "the change was purely cosmetical" wording?

-- 
Bye, Peter Korsgaard