Received-SPF: pass (google.com: domain of linux-kernel+bounces-156523-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <5ef0ac71-21dd-46d7-a0c1-1b1b391e51a8@leemhuis.info>
Date: Wed, 24 Apr 2024 10:09:35 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: API break, sysfs "capability" file
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@kernel.org>,
 Linux regressions mailing list <regressions@lists.linux.dev>,
 linux-block@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
 Lennart Poettering <mzxreary@0pointer.de>
References: <ZhQJf8mzq_wipkBH@gardel-login>
 <54e3c969-3ee8-40d8-91d9-9b9402001d27@leemhuis.info>
 <ZhQ6ZBmThBBy_eEX@kbusch-mbp.dhcp.thefacebook.com>
 <ZhRSVSmNmb_IjCCH@gardel-login>
 <ZhRyhDCT5cZCMqYj@kbusch-mbp.dhcp.thefacebook.com>
 <ZhT5_fZ9SrM0053p@gardel-login> <20240409141531.GB21514@lst.de>
 <d7a2b07c-26eb-4d55-8aa7-137168bd0b49@kernel.dk>
 <Zh6IpqnSfGHXMjVa@gardel-login>
 <b74f99e8-5a50-4e93-987f-0bcfc0c27959@kernel.dk>
 <Zh6KZ7ynHuOd0mgQ@gardel-login>
 <c3a6a639-bf15-4f8b-abbd-978d9836d93c@kernel.dk>
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@leemhuis.info>
Content-Language: en-US, de-DE
Reply-To: Linux regressions mailing list <regressions@lists.linux.dev>
In-Reply-To: <c3a6a639-bf15-4f8b-abbd-978d9836d93c@kernel.dk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.04.24 16:33, Jens Axboe wrote:
> On 4/16/24 8:25 AM, Lennart Poettering wrote:
>> On Di, 16.04.24 08:22, Jens Axboe (axboe@kernel.dk) wrote:
>>> On 4/16/24 8:18 AM, Lennart Poettering wrote:
>>>> On Di, 09.04.24 09:17, Jens Axboe (axboe@kernel.dk) wrote:
>>>>
>>>>> On 4/9/24 8:15 AM, Christoph Hellwig wrote:
>>>>>> On Tue, Apr 09, 2024 at 10:19:09AM +0200, Lennart Poettering wrote:
>>>>>>> All I am looking for is a very simple test that returns me a boolean:
>>>>>>> is there kernel-level partition scanning enabled on this device or
>>>>>>> not.
>>>>>> And we can add a trivial sysfs attribute for that.
>>>>>
>>>>> And I think we should. I don't know what was being smoked adding a sysfs
>>>>> interface that exposed internal flag values - and honestly what was
>>>>> being smoked to rely on that, but I think it's fair to say that the
>>>>> majority of the fuckup here is on the kernel side.
> [...]
> Doesn't really change my conclusion from earlier. As mentioned, this is
> clearly a kernel fuckup, and honestly since it's being presented as ABI,
> we definitely need to rectify this and provide an alternative. Even
> though I'm not a huge fan of it, might just be best to re-introduce
> 'capability' and just have conversions of the flags so we retain the
> user side of it the same. That can then also go into stable, so we'll
> end up with something that at least looks cohesive on the user side.

Jens, quick question: what's the plan forward here and who will realize
what you outlined?

I'm asking, as afaics nothing happened for a week (hope I didn't miss
anything!). Sure, it's not a regression from the last cycle or so, so
it's not that urgent. But hch's "It is not a regression at all" last
week made me worry that this in the end might not be solved unless
somebody has it on the todo list. Normally I would have CCed Linus at
that point anyway to get his stance, but from your statements it sounds
like this is unnecessary here.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.