Date: Thu, 21 Sep 2000 13:26:55 +0900 From: Mitsuru IWASAKI <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 Subject: Re: cvs commit: src/sys/dev/acpi/aml aml_evalobj.c aml_evalobj.h aml_obj.c aml_parse.c Message-ID: <20000921132655G.iwasaki@jp.FreeBSD.org> In-Reply-To: <200009210015.RAA00846@mass.osd.bsdi.com> References: <200009202253.PAA59611@freefall.freebsd.org> <200009210015.RAA00846@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
# 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.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000921132655G.iwasaki>