From: Kay Sievers on
On Thu, Mar 11, 2010 at 23:56, Johannes Berg <johannes(a)sipsolutions.net> wrote:
> When we use request_firmware_nowait(), userspace may
> not want to answer negatively right away when for
> example it is answering from an initrd only, but
> with request_firmware() it has to in order to not
> delay the kernel boot until the request times out.
>
> This allows userspace to differentiate between the
> two in order to be able to reply negatively to async
> requests only when all filesystems have been mounted
> and have been checked for the requested firmware file.

The firmware_class already always exports a TIMEOUT= value, right? If
this is the case, it should be set to 0, I guess.

Sounds fine to have a flag like this, while "NOWAIT" is, I guess, a
pretty bad name from the event perspective. This name might make sense
for the called kernel function, but not so much for a firmware loader
instruction.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Berg on
On Fri, 2010-03-12 at 05:21 +0100, Kay Sievers wrote:
> On Thu, Mar 11, 2010 at 23:56, Johannes Berg <johannes(a)sipsolutions.net> wrote:
> > When we use request_firmware_nowait(), userspace may
> > not want to answer negatively right away when for
> > example it is answering from an initrd only, but
> > with request_firmware() it has to in order to not
> > delay the kernel boot until the request times out.
> >
> > This allows userspace to differentiate between the
> > two in order to be able to reply negatively to async
> > requests only when all filesystems have been mounted
> > and have been checked for the requested firmware file.
>
> The firmware_class already always exports a TIMEOUT= value, right? If
> this is the case, it should be set to 0, I guess.

Yes and no. It is exported, but typically it will be 60 seconds. And
even in this case it makes sense to eventually time out when userspace
is not responding.

> Sounds fine to have a flag like this, while "NOWAIT" is, I guess, a
> pretty bad name from the event perspective. This name might make sense
> for the called kernel function, but not so much for a firmware loader
> instruction.

Yeah, I can agree with that. How about "ASYNC" or so? It needs to
distinguish between "I'm going to wait for this please respond" and "I'm
not really waiting, please let me now when you can".

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on
On Fri, Mar 12, 2010 at 05:46, Johannes Berg <johannes(a)sipsolutions.net> wrote:
> On Fri, 2010-03-12 at 05:21 +0100, Kay Sievers wrote:
>> The firmware_class already always exports a TIMEOUT= value, right? If
>> this is the case, it should be set to 0, I guess.
>
> Yes and no. It is exported, but typically it will be 60 seconds. And
> even in this case it makes sense to eventually time out when userspace
> is not responding.

Ok, I didn't expect the async version to time out. Sounds fine then.

>> Sounds fine to have a flag like this, while "NOWAIT" is, I guess, a
>> pretty bad name from the event perspective. This name might make sense
>> for the called kernel function, but not so much for a firmware loader
>> instruction.
>
> Yeah, I can agree with that. How about "ASYNC" or so? It needs to
> distinguish between "I'm going to wait for this please respond" and "I'm
> not really waiting, please let me now when you can".

Yeah, sounds fine to me.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/