On Mi, 17.04.24 17:13, Christoph Hellwig (hch@xxxxxx) 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
