On Tue, Jun 6, 2017 at 11:25 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Tue, Jun 06, 2017 at 09:56:47PM -0700, Andy Lutomirski wrote: >> On Tue, Jun 6, 2017 at 5:22 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: >> > On Tue, Jun 06, 2017 at 06:11:51PM -0400, Theodore Ts'o wrote: >> >> On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote: >> >> > On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote: >> > >> > We rely on swait, and swait right now only uses -ERESTARTSYS. Are >> > you saying we could mask out -ERESTARTSYS and map it to -ERESTARTNOINTR >> > or -ERESTARTNOHAND if we see fit for some future functionality / need ? >> >> I think that has essentially nothing to do with swait. User code does >> some syscall. That syscall triggers a firmware load. The caller gets >> a signal. If you're going to let firmware load get interrupted, you >> need to consider what the syscall is. > > I think it is way too complicated and I do not think driver writers will > stand a chance of implementing this correctly, given that often firmware > load might be triggered indirectly and by multitude of syscalls. > That's what I meant, but I said it unclearly. I meant that, if we're going to start allowing interruption, we would need to audit all the callers. Ugh. I suppose we could have request_firmware_interruptable(), but that seems like it's barely worth it. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
