> It's not clear to me how breaking I/O operations allows you to do a > "force eject". It seems that what you would need is something like > fsg_store_file() that omits the curlun->prevent_medium_removal check. > Interrupting a lengthy I/O operation doesn't really have anything to do > with this. Perhaps I chose the wrong path, it's just how my userspace code works now. If the drive is connected to a Linux host, then in order to clear the "file" and extract the image, I sent a SIGUSR1 signal to the "file-storage" thread. This interrupted long IO operations, reset curlun->prevent_medium_removal and I got the ability to extract. It was done in our KVM-over-IP project and worked for several years, just now I want to do it without searching for procfs and the need to use sudo helpers like this: https://github.com/pikvm/kvmd/blob/1b3a2cc/kvmd/helpers/otgmsd/unlock/__init__.py Maybe it's worth introducing some option that will allow us to ignore curlun->prevent_medium_removal and perform a forced extraction? Something like "allow_force_eject" on the same lavel with "stall". Will masking the curlun->prevent_medium_removal flag be enough? > Or to keep this ability restricted to the superuser, if that is desired. Indeed. > You should not call send_sig_info() directly; instead call > raise_exception(). It already does the work you need (including some > things you left out). raise_exception() assumes the setting of a new state, and I did not want to do this, since the same does not happen when throwing a signal from userspace.
