From owner-acpi-jp@jp.FreeBSD.org Tue Dec 18 02:34:06 2001
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id fBHHY6Q83607;
	Tue, 18 Dec 2001 02:34:06 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id fBHHY6683601
	for <acpi-jp@jp.FreeBSD.org>; Tue, 18 Dec 2001 02:34:06 +0900 (JST)
	(envelope-from jhb@FreeBSD.org)
Received: (qmail 26893 invoked from network); 17 Dec 2001 17:34:04 -0000
Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender <jhb@FreeBSD.org>)
          by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <iwasaki@jp.FreeBSD.org>; 17 Dec 2001 17:34:04 -0000
Message-ID: <XFMail.011217093351.jhb@FreeBSD.org>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20011217.130855.59541211.iwasaki@jp.FreeBSD.org>
Date: Mon, 17 Dec 2001 09:33:51 -0800 (PST)
From: John Baldwin <jhb@freebsd.org>
To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>
Cc: acpi-jp@jp.FreeBSD.org
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+010331
X-Sequence: acpi-jp 1546
Subject: [acpi-jp 1546] RE: Call for testers: Semaphore and Thread im
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: jhb@FreeBSD.org


On 17-Dec-01 Mitsuru IWASAKI wrote:
> Thanks John!
> 
>> One minor nit that's new: __func__ apparently can't be concatenated with
>> strings as it is not a constant, but a variable, so you need to use
>> panic("%s ...", __func__, ...) when the kthread_create() for the taskqueue
> 
> OK, I'll do so.  Shall I change following line in OsdSchedule.c as well?
>     KASSERT(curproc != NULL, (__func__ ": curproc is NULL!"));

Hmm, it should be curthread, not curproc, but curthread can't be cold except
very early on during booting.  (Before devices are probed.)

>> thread fails.  Also, why do you call the option ACPI_MAX_THREADS?  Why not
>> ACPI_TASK_KTHREAD or some such?
> 
> Because I'd like to reduce the number of options to be newly introduced.
> The threading code is enabled only if ACPI_MAX_THREADS is specified and
> has value greater than zero.  Also ACPI_MAX_THREADS can indicate the
> number of task thread simultaneously.
> Having ACPI_TASK_KTHREAD and ACPI_MAX_THREADS looks insistent a bit for me.

Fair enough for now.  If we introduce some other type of thread for ACPI at
some point, then we might end up with a problem as to which thread gets enabled
for ACPI_MAX_THREADS == 1. :)

> Thanks

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
