[Bug 223519] __BUS_ACCESSOR doesn't check return value of BUS_READ_IVAR

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Nov 9 23:50:32 UTC 2017


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223519

John Baldwin <jhb at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Closed
         Resolution|---                         |Works As Intended

--- Comment #1 from John Baldwin <jhb at FreeBSD.org> ---
Unfortunately, this is inherent in the design of __BUS_ACCESSOR.  There is no
universal value to return to indicate an invalid ivar (e.g. ivars can have a
value of -1).  In essence, the assumption is that _BUS_ACCESSOR is a
convenience wrapper for ivars that are always valid.  One should use
BUS_READ_IVAR() directly if one wishes to handle possibly invalid ivars.

The ACPI ivars accessors use a different macro that returns a default value of
0 so that acpi_get_handle() will "fail" properly, but that is only ok for ACPI.

I think it would perhaps be useful to extend the ACPI model slightly to have a
__BUS_ACCESSOR_DEFAULT() that accepts an additional "default value" parameter
which is returned if BUS_READ_IVAR fails perhaps?  That could replace the ACPI
macro and be useful for other cases since on an individual ivar you might be
able to return a suitable value for error.

In general with ivars I have wanted a way to name them by a tuple (group,
index) (ACPI just starts indices at 100 to get around this) and then have a way
to say "do you have this group".  This would let you ask a given device "do you
have PCI ivars" (i.e. are you a PCI device).  However, this would require
restructuring ivars a bit.  That wouldn't help with your bug where a single
ivar out of a group was not properly implemented either.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list