Received-SPF: pass (google.com: domain of linux-kernel+bounces-148846-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 17 Apr 2024 17:48:16 +0200
From: Lennart Poettering <mzxreary@0pointer.de>
To: Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <kbusch@kernel.org>,
	Linux regressions mailing list <regressions@lists.linux.dev>,
	linux-block@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>
Subject: Re: API break, sysfs "capability" file
Message-ID: <Zh_vQG9EyVt34p16@gardel-login>
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>
 <Zh6J75OrcMY3dAjY@gardel-login>
 <Zh6O5zTBs5JtV4D2@kbusch-mbp>
 <20240417151350.GB2167@lst.de>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240417151350.GB2167@lst.de>

On Mi, 17.04.24 17:13, Christoph Hellwig (hch@lst.de) wrote:

> On Tue, Apr 16, 2024 at 08:44:55AM -0600, Keith Busch wrote:
> > The patch that introduced this was submitted not because the API was
> > stable; it was committed to encourage developers to update it as it
> > changed because it is *not* stable. That's not the kind of interface you
> > want exported for users to rely on, but no one should have to search
> > commit logs to understand why the doc exists, so I think exporting it
> > was just a mistake on the kernel side. To say this doc is "good"
> > misunderstands what it was trying to accomplish, and what it ultimately
> > created instead: technical debt.
>
> Yes.  It might be a problem with the documentation generation mess,
> but something that is generated from a random code comment really
> can't be an API document.
>
> Anyway, instead of bickering about this, what does systemd actually
> want to known?  Because all these flags we talked about did slightly
> different things all vaguely related to partition scanning.
> We also have another GD_SUPPRESS_PART_SCAN bit that is used to
> temporarily suppress partition scanning (and ublk now also abuses
> it in really whacky way, sigh).  I'm not really sure why userspace
> would even care about any of this, but I'm open to come up with
> something sane if we can actually define the semantics.

systemd works a lot with partitioned GPT disk images, and many of our
tools you can point to such images, either by referencing a file or by
referencing a block device. We generally handle that
transparently. Typically we then look at the GPT partition table from
userspace, and then do something with the associated partition block
devices (i.e. mount them or so). But those will only be synthesized by
the kernel if we are operating on a block device with partition
scanning on. Since kernel part scanning is async if a partition block
device doesn#t exist yet could have two reasons: part scanning is off
for the device, or the part table is still read and processed by the
kernel. By being able to read the part scan flag off the block device
we know which case it is, and can avoid a potential time-out.

If we are operating on a regular file or on a block device with
partition scanning off, we first have to generate an intermediary
loopback block device off it, whith scanning on.

Hence it's very useful to be able to determine if we a block device
already supports partition scans, simply so that we can do all this
entirely generically: you give us anything and we can handle it.

Block devices with part scanning off are quite common after all,
i.e. "losetup" creates them by default like that, and partition block
devices themselves have no part scanning on and so on, hence we have
to be ablet to operate sanely with them.

Lennart

--
Lennart Poettering, Berlin