lkml.org 
[lkml]   [2022]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] usb: gadget: f_mass_storage: break IO operations via configfs
> 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.

\
 
 \ /
  Last update: 2022-04-06 20:18    [W:0.096 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site