From: Nate Lawson <nate-Y6VGUYTwhu0@public.gmane.org>
To: "Moore, Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Alex Williamson <alex.williamson-VXdhtT5mjnY@public.gmane.org>,
acpi-devel
<acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: NO_RETURN_VALUE w/ 20040715
Date: Mon, 23 Aug 2004 14:26:35 -0700 [thread overview]
Message-ID: <412A610B.90300@root.org> (raw)
In-Reply-To: <37F890616C995246BE76B3E6B2DBE05501C71EF2-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
I don't think that approach will be helpful. Instead, I think it should
be "if argument types differ and any arg is an integer, convert the
other to an integer." If not, error AE_TYPE. We have something like
this in FreeBSD where we found on older systems many methods that are
supposed to return an integer returned a buffer instead. So many that
we added an automatic conversion for this to acpi_GetInteger(). Also, I
found a system that uses a package of integers for _FDE instead a buffer
of integers.
In summary, I've seen a lot of buffers used where integers were expected
but never an integer expected to be converted to a buffer.
-Nate
Moore, Robert wrote:
> I will prototype this using the existing internal mechanisms for
> implicit object conversion.
>
> However, I'm not sure how or if this statement will work as expected:
>
>
>>>>>If (LEqual (Local0, 0x00))
>>>>>{
>
>
> since Local0 is a buffer, 0x00 will be converted to a buffer before the
> compare.
>
>
>
>>-----Original Message-----
>>From: Alex Williamson [mailto:alex.williamson-VXdhtT5mjnY@public.gmane.org]
>>Sent: Monday, August 23, 2004 1:34 PM
>>To: Moore, Robert
>>Cc: acpi-devel
>>Subject: RE: [ACPI] NO_RETURN_VALUE w/ 20040715
>>
>>Bob,
>>
>> Great, I was looking through the history of the LEqual operator
>
> across
>
>>the ACPI specs and it got rather convoluted, this seems like a good
>>compromise. Will there be a CA update to support this (preferably in
>>Linus' tree before 2.6.9 is tagged)? I'd be happy to test on this box
>>if needed. Thanks,
>>
>> Alex
>>
>>On Mon, 2004-08-23 at 13:22 -0700, Moore, Robert wrote:
>>
>>>We are going to update the ACPI spec to something like this:
>>>
>>>* For the following operators, the data type of the first operand
>>>dictates both the required type of the second operand and the type
>
> of
>
>>>the result object. (The second operator is converted, if necessary,
>
> to
>
>>>match the type of the first operand.)
>>> Concatenate
>>> LEqual
>>> LGreater
>>> LGreaterEqual
>>> LLess
>>> LLessEqual
>>> LNotEqual
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
next prev parent reply other threads:[~2004-08-23 21:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-23 20:46 NO_RETURN_VALUE w/ 20040715 Moore, Robert
[not found] ` <37F890616C995246BE76B3E6B2DBE05501C71EF2-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-08-23 21:26 ` Nate Lawson [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-08-23 22:05 Moore, Robert
2004-08-23 21:54 Moore, Robert
[not found] ` <37F890616C995246BE76B3E6B2DBE05501C72022-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-08-23 22:01 ` Nate Lawson
2004-08-23 20:22 Moore, Robert
[not found] ` <37F890616C995246BE76B3E6B2DBE05501C71E7A-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-08-23 20:34 ` Alex Williamson
2004-08-20 21:07 Moore, Robert
[not found] ` <37F890616C995246BE76B3E6B2DBE05501C19B93-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-08-20 23:17 ` Alex Williamson
2004-08-20 20:31 Moore, Robert
2004-08-20 20:11 Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=412A610B.90300@root.org \
--to=nate-y6vguytwhu0@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=alex.williamson-VXdhtT5mjnY@public.gmane.org \
--cc=robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox