I agree. I was just thinking that ACPI was correct already, and we
could move on toward making it fast and small. Sorry for thinking that
:)
> I'm used to ACPI ranting from all quarters, you know that ;-) but let me
> just say this:
>
> - ACPI is not performance-critical
> - ACPI will never be simple and elegant, even if you made it Linux-specific
> - Portability enhances correctness and maximizes developer productivity
> - Read my lips, no new taxes!
>
> (dunno where that last one came from ;-)
You already said 3 other lies, so a fourth one rounded them all out? :)
(sorry, couldn't help myself. For the readers in the peanut gallery,
I consider Andy a friend, this was not a personal attack, just a chance
to make a joke.)
To address the above:
> - ACPI is not performance-critical
But it can't hurt in both stack size, and execution speed to fix obvious
things that cause it to slow down. And if ACPI is too slow, booting
takes longer, and getting ACPI events to other places start taking
unacceptable amounts of times. Not that this is happening right now :)
> - ACPI will never be simple and elegant, even if you made it Linux-specific
Heh, you said it, I didn't.
> - Portability enhances correctness and maximizes developer productivity
Only if the developers are being forced to work on multiple platforms.
For the majority of Linux kernel developers, luckily we do not have to
do this. For your group, I understand the constraints, and am willing
to live with it, in order to get a working ACPI implementation. Beggars
can't be choosy :)
thanks,
greg k-h
-
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/