On Mi, 07.05.25 09:07, Phillip Susi (ph...@thesusis.net) wrote: > Lennart Poettering <lenn...@poettering.net> writes: > > > Maybe in your case, in the general case that's not so however. People > > often dd images to disks, and hence it's essential the partitions show > > up once that's complete. > > I think you have that backwards. That is, it is taken care of in the > general case, and only not in the case where someone uses dd to write a > whole disk image ( and honestly, that is a terrible way to image a disk > ).
Is it? I do that all the time? It's news to me that this wasn't a good idea... > In that case, people can run blockdev or partprobe or partx to > activate the partitions, like they had to before udev started doing it > automatically. You are aware that the automatic logic has been around since literally more than a decade? > > If you want to do userspace partition scanning, then this would need > > some kernel changes first (because you'd have to turn off the kernel's > > own scanner, so that you don#t race against that), and you'd have to > > call your tool from udev, so that it always is run when a device pops > > up. As long as your do your changes from your own tool, that is called > > independently of that you should really take the lock to indicate > > clearly you want no interference, and we'll accept that and respect > > it. But if you give up all locks then the kernel's and udev's > > management takes control again. I think that's a very reasonable > > approach. > > Taking the lock doesn't prevent the interference; it only delays it. It's an advisory lock, true. But systemd won't interfere while you take it. And it will only issue the ioctl once it successfully took it itself. Hence, at that point it's in exclusive possession of the device, hence will not interfere with any other owner, because there cannot be one. Hence, there is no interference. Lennart -- Lennart Poettering, Berlin
