From owner-acpi-jp@jp.freebsd.org  Thu Sep 21 13:29:05 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id NAA13929;
	Thu, 21 Sep 2000 13:29:05 +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 NAA13924
	for <acpi-jp@jp.freebsd.org>; Thu, 21 Sep 2000 13:29:04 +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 e8L4T1r70667;
	Thu, 21 Sep 2000 13:29:01 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
To: msmith@freebsd.org
Cc: iwasaki@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org,
        acpi-jp@jp.freebsd.org
In-Reply-To: <200009210015.RAA00846@mass.osd.bsdi.com>
References: <200009202253.PAA59611@freefall.freebsd.org>
	<200009210015.RAA00846@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: <20000921132655G.iwasaki@jp.FreeBSD.org>
Date: Thu, 21 Sep 2000 13:26:55 +0900
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 111
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 653
Subject: [acpi-jp 653] 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.

Hi, mike!

> I'd really like to be able to invoke methods that take arguments and 
> return values, actually.  To do this "more or less" right will require 
> something like a printf format string.  The best proposal I've come up 
> with so far goes something like this:
> 
> int aml_invoke_method(name, format, ...)
> 
> where 'name' is the AML method's name (probably an aml_name, actually), 
> and 'format' is a printf-like string.  

Currently, aml_invoke_method() takes array of union aml_object as the
arguments and each union aml_object contains aml_objtype member (yes,
this describes the type of argument value).  Difference between
aml_invoke_method() and aml_invoke_method_by_name() is only how to
specify method to be invoked (in pointer to the named object or in
name string like "\_SB_.PCI0.LAN_._PRW").

For example, following finds the named object "_PSW" (7.3.2 in spec.) 
under the specified device object and invokes it to enable the
devices's wake capability from the system sleep state.  The interface
of _PRW control method is like this
	Arguments:
	0:	Enable/Disable	0 to disable the device's wake capability
				1 to enable the device's wake capability
	Result code:
	None

and actual code using aml_invoke_method() is like this

	struct  aml_name *method;
        union   aml_object argv[1], *retval;

	/* find the named object "_PSW" under the specified device object */
        method = aml_find_from_namespace(device, "_PSW");
        if (method == NULL) {
                return;
        }

	/* prepare argument values for _PSW control method invoking */
        argv[0].type = aml_t_num; /* the type of the first argument is numeric */
        argv[0].num.number = 1;	/* 1 to enable the device's wake capability */

        retval = aml_invoke_method(method, 1, argv); /* result will be discard */

If we already know the number/type of arguments (and result code) for
the method, I think the method invocations in this style would be enough.
Preparing storage for the arguments maybe little bit troublesome though...

But I understand that we'd better to have simpler level of control
method invocation mechanism as you suggested.  We can design it
together in future.

> The first format specifier in the format should describe the value that 
> the method is expected to return.  It should be %* if the method does not 
> return anything.  The remaining specifiers in the format string should 
> describe arguments to be placed on the stack for the method.  I would 
> stack from left to right (even though C stacks the other way around) for 
> simplicity's sake.

Sounds good.

> You'd use format specifiers specific to the AML object types, eg.
> 
> 	%*	nothing (ignored)
> 	%n	aml_t_namestr = -3,
>         %r	aml_t_regfield,
>         %o	aml_t_objref,
>         %0	aml_t_null = 0,
>         %d	aml_t_num,
>         %s	aml_t_string,
>         %b	aml_t_buffer,
>         %p	aml_t_package,
>         %D	aml_t_device,
>         %f	aml_t_field,
>         %e	aml_t_event,
>         %m	aml_t_method,
>         %M	aml_t_mutex,
>         %o	aml_t_opregion,
>         %P	aml_t_powerres,
>         %C	aml_t_processor,
>         %T	aml_t_therm,
>         %B	aml_t_bufferfield,
>         %x	aml_t_ddbhandle,
>         %X	aml_t_debug
> 
> Note that the leading '%' is actually redundant, and leaving it out 
> wouldn't hurt anything.  You might also want to put a separator between 
> the return value and arguments, eg. a method that takes two numeric 
> values and returns a string would have a format of "%s:%d%d".

OK, it's like aml_invoke_method("\\_PTS", "%*:%d", 1), here we don't
need to prepare any aml_object array for the arguments.  It would be
nicer.

> This would make it very easy to invoke arbitrary methods without the 
> cumbersome glue currently involved in initialising a context and then 
> stacking variables manually.  (I still don't understand how to stack 
> variables into an aml_environment rather than just the local stack 
> anyway...)

We had the problems with the life time of temprorary object and memory
leakage, so the code related with this is somehow messy :-)
Of course this is in our TODO list but priority is not so high...

> Just a thought...

Thanks for your suggestion.
