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:

quoted

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