public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Lennart Poettering <mzxreary@0pointer.de>
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>
Subject: Re: API break, sysfs "capability" file
Date: Tue, 16 Apr 2024 08:33:07 -0600	[thread overview]
Message-ID: <c3a6a639-bf15-4f8b-abbd-978d9836d93c@kernel.dk> (raw)
In-Reply-To: <Zh6KZ7ynHuOd0mgQ@gardel-login>

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.
>>>
>>> Yeah, it's a shitty interface, the kernel is rich in that. But it was
>>> excessively well documented, better in fact than almost all other
>>> kernel interfaces:
>>>
>>> ? https://www.kernel.org/doc/html/v5.16/block/capability.html ?
>>>
>>> If you document something on so much detail in the API docs, how do
>>> you expect this *not* to be relied on by userspace.
>>
>> This is _internal_ documentation, not user ABI documentation. The fact
>> that it's talking about internal flag values should make that clear,
>> though I can definitely see how that's just badly exposed along with
>> other things that document things that users/admins could care about.
> 
> The text begins with:
> 
>     "This file documents the sysfs file block/<disk>/capability."
> 
> So it makes very clear this is about the sysfs interface.
> 
> Are you saying that sysfs of the block layer should be considered an
> *internal* kernel API? That's a wild definition, if I may say so.

No I missed that - to me it's clearly internal documentation as it's
talking about the flags, but yeah you are right it's being presented as
sysfs documentation for the 'capability' file. That should never have
gone into the tree as ABI documentation.

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 Axboe


  reply	other threads:[~2024-04-16 14:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-08 15:13 API break, sysfs "capability" file Lennart Poettering
2024-04-08 17:43 ` Linux regression tracking (Thorsten Leemhuis)
2024-04-08 18:41   ` Keith Busch
2024-04-08 20:23     ` Lennart Poettering
2024-04-08 22:41       ` Keith Busch
2024-04-09  6:09         ` Hannes Reinecke
2024-04-09  8:19         ` Lennart Poettering
2024-04-09 14:15           ` Christoph Hellwig
2024-04-09 15:17             ` Jens Axboe
2024-04-16  9:26               ` Linux regression tracking (Thorsten Leemhuis)
2024-04-17 15:07                 ` Christoph Hellwig
2024-04-16 14:18               ` Lennart Poettering
2024-04-16 14:22                 ` Jens Axboe
2024-04-16 14:25                   ` Lennart Poettering
2024-04-16 14:33                     ` Jens Axboe [this message]
2024-04-24  8:09                       ` Linux regression tracking (Thorsten Leemhuis)
2024-04-25 13:08                         ` Christoph Hellwig
2024-04-16 14:23             ` Lennart Poettering
2024-04-16 14:44               ` Keith Busch
2024-04-17 15:13                 ` Christoph Hellwig
2024-04-17 15:48                   ` Lennart Poettering
2024-04-17 15:59                     ` Christoph Hellwig
2024-04-17 16:10                       ` Lennart Poettering
2024-04-17 16:22                         ` Christoph Hellwig
2024-04-17 16:26                           ` Lennart Poettering
2024-04-17 16:38                             ` Christoph Hellwig
2024-04-18  6:28                       ` Hannes Reinecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3a6a639-bf15-4f8b-abbd-978d9836d93c@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mzxreary@0pointer.de \
    --cc=regressions@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox