On Wed, Dec 30, 2009 at 08:49:32PM -0500, Constantine Aleksandrovich Murenin wrote: > 2009/12/30 Jukka Ruohonen <[email protected]>: > > The correct type for these would probably be uint64_t, given the relation to > > the type ACPI_INTEGER, which AFAIR is an unsigned 64-bit integer (from ACPI > > 2.0 onwards). Or maybe even plain ACPI_INTEGER? > > Yes, this sounds good -- I'll try changing all of these to ACPI_INTEGER.
The other places where int64_t is used could be changed as well, if appropriate. > ACPI_ALLOCATE_LOCAL_BUFFER is not documented in the latest > http://www.acpica.org/download/acpica-reference.pdf (Revision 1.26, > from October 2009). Is there any principal difference between the > two? > > ACPICA Reference, Section 3.2.2.2, "ACPI Allocates Return Buffers", > explicitly suggests the use of AcpiOsFree(). Is it wrong? Like in any good [...] API, a lot of things in ACPICA are not documented. Both of these allow tracking the internal memory usage of ACPICA when compile-time debugging options are defined. But nothing wrong as such. At the end of the day ACPICA just hammers malloc() and free(). > >> + as = malloc(sizeof(*as) * n, M_DEVBUF, M_NOWAIT | M_ZERO); > > > > I reckon that there is no reason to prefer malloc(9) instead of kmem(9). > > I didn't use kmem(9) since that would require knowing the size of the > structure on kmem_free(9). Ah yes. The size (or 'n') could be recorded, but I am not sure if it is worth the cause. > it'll be more useful. I'd prefer the driver to be as cross-portable > as possible, though, and acpica functions seem like a natural choice > for such a direction. That is of course a good approach. > > These should probably be %"PRId64" (or %"PRIx64" with uint64_t). > > Sure, looks good... Actually, what's the purpose of this? Is > sizeof(unsigned long long) greater than sizeof(uint64_t) on amd64? If > not, then why do you have to change llx to lx? :/ Someone wiser has to answer this one :). - Jukka.
