patch: change in acpi taskq behavior

[Nate Lawson]

Jung-uk Kim wrote:
> On Sunday 30 September 2007 04:10 pm, Nate Lawson wrote:
>> Attached is a patch (one for 6, one for 7) that shouldn't break
>> anything for most people and may fix some battery status issues for
>> others.  It changes how we run tasks during boot.  It seems some
>> hardware expects synchronous access but our taskq is not running
>> until after interrupts are enabled.  This patch bounces calls
>> through a wrapper that executes the callback directly if we're not
>> booted yet.
> 
> Sorry, I didn't test it but I have some questions.  Why do you add a 
> wrapper and pollute all AcpiOsQueueForExecution()/AcpiOsExecute() 
> consumers?  Isn't it more simpler to let the function determine to 
> queue or not to queue?  Why do you check cold and rebooting flags?  
> If you wanted to check the taskqueue is ready, you could check 
> taskqueue_acpi is NULL or not, instead.

There are 2 different behaviors I'm trying to support and only the
caller knows which one they want:

1. Run a task at some point in the future but "soon"
2. Queue a task to be run, definitely after boot is complete

Notifies are in the first class.  Initialization functions for the
various drivers are in the second.  ACPI-CA is moving to making all
Notifies completely synchronous (i.e. they wait for the thread to run).
 So if we go to the model you describe (#1), this will work but suddenly
the initialization of the drivers won't wait for boot.  It will be run
right away.

-- 
Nate