Date: Wed, 03 Oct 2007 09:04:29 -0700 From: Nate Lawson <nate@root.org> To: Jung-uk Kim <jkim@FreeBSD.org> Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: patch: change in acpi taskq behavior Message-ID: <4703BD8D.1080501@root.org> In-Reply-To: <200710031138.28820.jkim@FreeBSD.org> References: <470002B5.6030002@root.org> <200710031138.28820.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4703BD8D.1080501>