On Mon, 2007-08-27 at 16:02 +0100, Hugh Dickins wrote: > Fix 61ec7567db103d537329b0db9a887db570431ff4: maxcpus=N is now having no > effect on x86_64, and freezing bootup on i386 (because of inconsistency > with the separate maxcpus parsing down in arch/i386, I guess). That's > because early_param parsing is a little different from __setup parsing, > and needs the "=" omitted: then it seems to work as the original commit > intended (no mention of IO-APIC in /proc/interrupts when maxcpus=0). > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > --- > Sorry, I noticed this back in -mm, but got diverted by deeper mysteries. > Cc'ed Rusty: I presume there's a good reason why early_param parsing is > confusingly different, but he may know better and want to change it.
Yeah, early_param is modelled on module_param which does more than the naive substring match of __setup. There's a warning in the header IIRC. The original intention wass that everything would move to module_param-style parameters. However __setup is still useful for trivial core stuff. > It's odd that i386 treats maxcpus=N differently from other architectures: > on i386 it limits cpu_possible_map, on others it just limits what boots > (then powersaved is liable to bring up the others on x86_64 - hmmm). Indeed, it'd be nice to see this made uniform. But this patch is fine. Cheers, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
