Well, let me be the first to appologize. I need to do a better job of
separating my frustrations so that people like you don't get dumped on.
(Yes, I do have this problem and I am addressing it, just haven't
totally beaten it yet). I am sorry.
> OK, lets see ... the power off changes add 1 variable (4 bytes), and
> the passing of 1 integer in two places in the kernel (8 bytes), and add
> two tests. One of these is in the code that is executed when you are
> trying to power off your machine and the other is in the initialisation
> code that is discarded after the kernel is initialised. Total 12 bytes
> in the running kernel and 1 test that is hardly in the "common path"!
This isn't as bad as I figured this was. The poweroff one wasnt the one
I was worried about, it was the debug one more than anything. So it
seems the above was a false concern of mine (small small addition of
bytes in RAM).
> The debug change does actually add about 140 bytes af data to the
> kernel. It also adds 1 test to the code. This test is in the
> routine that gets events from the BIOS and believe me, calling the
> BIOS swamps anything we do! What do we gain? Well when people
> report problems, I used to have to say "Please edit apm.c and define
> APM_DEBUG and then rebuild the kernel and then reproduce the problem
> and tell me what you get in your logs" now I can say "reboot and
> pass apm=debug to the kernel and ...". Can you see how I can
> justify this?
>
> If you have ANY problems of substance, please let us know ...
>
> Cheers,
> Stephen
I will respond to this in reverse order. I can see your point, you gain
a lot... is it possible to have a #ifdef APM_NO_DEBUG or similar for
those who have little/no problems when running APM to remove that 140
bytes of data, the one test, and whatever else is added?
My big worry is this, and yes I know this is insane, but right now where
the business I work is getting started, any savings helps (and power is
a big one). Our servers have APM configured as on. Currently the time
it takes for it to snap back to life is almost nil. I am worried that
the debug stuff MAY cause some slow down in it comming back to life; in
going to sleep, I don't really care, take an extra 2 seconds (yes, this
is exagerated, but literally I wouldn't mind) to fall asleep. Is my
worry justified about waking up? I don't know what your code and test
all include.. I suppose I should have read your patch in the first place
instead of freaking out.
In light that Linux is supposed to be the land of chosing what is in
your kernel though, I do ask that you keep these things to a minimum. I
do see your logi on the debug, still don't like the power off but have
no problems with a total of what, 12 bytes... but others may.
Again, I appologize for my tone. I hope you will read my thoughts on
the matter now. I will also go and read your patch to see what I really
think.
Trever
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/