> From: Greg KH [mailto:[email protected]]
> Nice, thanks for pointing that out. But what about the fact that I
> think we can now start optimizing certain parts of the
> "generic" code to
> play nicer with Linux?
It is much much more important that ACPI be *correct* than fast or small. To
that end, it is better to not fork ACPI-Linux from ACPI-everyone else. Linux
benefits from core bugs found by other OSes (FBSD is not the only one - for
some reason I'm not allowed to mention who else is using ACPI CA but they
*do* send bug reports) and vice versa.
> Now I don't mean this to be an ACPI rant, I know why they did
> their code
> this way, and without it, there probably would not be any ACPI Linux
> code. I just don't think it's the best way (from an engineering
> standpoint) to do things. And again, we are getting way off
> topic from
> the original problem, sorry.
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 ;-)
Regards -- Andy
On Thu, Oct 31, 2002 at 06:07:31PM -0800, Grover, Andrew wrote:
> > From: Greg KH [mailto:[email protected]]
> > Nice, thanks for pointing that out. But what about the fact that I
> > think we can now start optimizing certain parts of the "generic"
> > code to play nicer with Linux?
>
> It is much much more important that ACPI be *correct* than fast or small.
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