[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: aibs(4): ASUSTeK AI Booster (ACPI ATK0110) hardware monitor with limit support
On Wed, Dec 30, 2009 at 08:49:32PM -0500, Constantine Aleksandrovich Murenin
> 2009/12/30 Jukka Ruohonen <jruohonen%iki.fi@localhost>:
> > 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
> 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
> ACPICA Reference, Section 188.8.131.52, "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 :).
Main Index |
Thread Index |