firmware class: export nowait to userspace
in [Kernel]
|
Prev: ST SPEAr: Added clock framework for SPEAr platform and machines
Next: ST SPEAr: Added ARM PrimeXsys System Controller SP810 header file
From: Kay Sievers on 11 Mar 2010 23:30 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 11 Mar 2010 23:50 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 12 Mar 2010 00:40
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/ |