> I think acpi_handle_t is "an opaque type specific to the OS on which the APCI
> code happens to be running".
I don't see how putting a spinlock_t cast in the code is any more
portable between OS's than spinlock_t as a function parameter.
> If the above guesses (I'd prefer not to look) are correct then
> struct acpi_handle_t {
> spinlock_t lock;
> };
>
> would make a ton more sense.
That would solve the portability argument in my eyes if that is
indeed the case here. It's still ugly, but it at least kills
the problem in a slightly more tasteful way.
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/