From owner-cvs-all Wed Sep 20 21:29:15 2000 Delivered-To: cvs-all@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id B534437B422; Wed, 20 Sep 2000 21:29:04 -0700 (PDT) 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 Subject: Re: cvs commit: src/sys/dev/acpi/aml aml_evalobj.c aml_evalobj.h aml_obj.c aml_parse.c 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 X-Dispatcher: imput version 20000228(IM140) Lines: 111 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message