From owner-acpi-jp@jp.freebsd.org  Thu Sep 21 16:01:30 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id QAA26112;
	Thu, 21 Sep 2000 16:01:30 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from tasogare.imasy.or.jp (daemon@tasogare.imasy.or.jp [202.227.24.5])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id QAA26103;
	Thu, 21 Sep 2000 16:01:27 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92])
	by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e8L71Or09882;
	Thu, 21 Sep 2000 16:01:24 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
To: acpi-jp@jp.freebsd.org, msmith@freebsd.org
Cc: iwasaki@jp.FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
In-Reply-To: <200009210435.VAA00733@mass.osd.bsdi.com>
References: <20000921132655G.iwasaki@jp.FreeBSD.org>
	<200009210435.VAA00733@mass.osd.bsdi.com>
X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000921155852T.iwasaki@jp.FreeBSD.org>
Date: Thu, 21 Sep 2000 15:58:52 +0900
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 29
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 657
Subject: [acpi-jp 657] Re: cvs commit: src/sys/dev/acpi/aml
 aml_evalobj.c aml_evalobj.h aml_obj.c aml_parse.c 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: iwasaki@jp.freebsd.org

> > # Cc acpi-jp because this is related with AML interpreter improvement.
> 
> A related question - since you've mentioned that you've considered using 
> the Intel ACPICA code (and I think this is a good idea unless there are 
> other reasons not to do so), what interfaces does it provide for this 
> sort of thing?

Oh, it's a very important suggestion :-)

We already have part of Osd* functions which is some sort of OS
abstraction layer, but don't have any interfaces between acpi driver
and the Intel ACPICA code for now.

I personally think that we can replace the interpreter code always if
we want to do so, but we need to evaluate their code (including
modifications in Linux) before we go.  We'd better to keep maintaining
our interpreter code until we agree to go with Intel code.

Comparing Linux 2.4.0-testX and the original Intel ACPICA code, I
noticed that there are too many changes between them more than naming
chages :-(   This fact is giving me a big hesitation actually...
We need to keep watching where these two development are going to.

Anyway, we should consult with Intel ACPICA Programmer Reference
whenever we create a new API to AML interpreter as possible in order
to make glue layer code development easier.  I think it's the best
thing we can do for now.

Thanks!
