Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out

Matt Mackall
2003-07-11T14:42:33Z

On Thu, Jul 10, 2003 at 03:30:22AM -0700, William Lee Irwin III wrote:
> On Thursday 10 July 2003 11:48, William Lee Irwin III wrote:
> > It's not the 64B...
> > I care about the unneeded but executed code!
> > But I'm a hopeless perfectionist caring about such nits...
>
> On Thu, Jul 10, 2003 at 11:59:49AM +0200, Thomas Schlichter wrote:
> > And I don't know why everybody hates my patches... ;-(
>
> It's not that anyone hates them, it's that
> pass 1: the semantics (0 == empty cpu set) needed preserving
> pass 2: remove code instead of changing redundant stuff
>
> NFI YTF gcc doesn't optimize out the whole shebang.

Probably would if inline were added to the function spec?

If we're going to worry about space, we'd start by worrying about the
existence of current->cpus_allowed in the UP case.

> At any rate, if we're pounding APM BIOS calls or apm_power_off()
> like wild monkeys there's something far more disturbing going wrong
> than 64B of code gcc couldn't optimize (it's probably due to some
> jump target being aligned to death or some such nonsense).

I much prefer the removal of #ifdef approach - would have prevented
the bug getting out in the first place.

--
Matt Mackall : http://www.selenic.com : of or relating to the moon