On Mi, 23.06.21 15:10, Matteo Croce (mcroce@linux.microsoft.com) wrote:

On Wed, Jun 23, 2021 at 1:49 PM Christoph Hellwig [off-list ref] wrote:

quoted

On Wed, Jun 23, 2021 at 12:58:53PM +0200, Matteo Croce wrote:

quoted

+void inc_diskseq(struct gendisk *disk)
+{
+     static atomic64_t diskseq;

Please don't hide file scope variables in functions.

I just didn't want to clobber that file namespace, as that is the only
point where it's used.

quoted

Can you explain a little more why we need a global sequence count vs
a per-disk one here?

The point of the whole series is to have an unique sequence number for
all the disks.
Events can arrive to the userspace delayed or out-of-order, so this
helps to correlate events to the disk.
It might seem strange, but there isn't a way to do this yet, so I come
up with a global, monotonically incrementing number.

To extend on this and given an example why the *global* sequence number
matters:

Consider you plug in a USB storage key, and it gets named
/dev/sda. You unplug it, the kernel structures for that device all
disappear. Then you plug in a different USB storage key, and since
it's the only one it will too be called /dev/sda.

With the global sequence number we can still distinguish these two
devices even though otherwise they can look pretty much identical. If
we had per-device counters then this would fall flat because the
counter would be flushed out when the device disappears and when a device
reappears under the same generic name we couldn't assign it a
different sequence number than before.

Thus: a global instead of local sequence number counter is absolutely
*key* for the problem this is supposed to solve

Lennart

--
Lennart Poettering, Berlin