Messages in this thread | | | Date | Tue, 17 Nov 2009 09:49:54 -0800 | From | Mike Travis <> | Subject | Re: [PATCH 3/6] INIT: Limit the number of per cpu calibration bootup messages |
| |
Cyrill Gorcunov wrote: > On Tue, Nov 17, 2009 at 08:29:28AM -0800, David Miller wrote: >> From: Cyrill Gorcunov <gorcunov@gmail.com> >> Date: Tue, 17 Nov 2009 18:59:46 +0300 >> >>> Perhaps for other archs like SPARC64, where as you said no need to >>> remember boot cpu id at all, we should define some __weak per-kernel >>> global helper which would return 0 and every arch would implement >>> own helper boot_cpu_id(). >> On many of my machines none of my cpus are numbered "0", so that >> wouldn't be a legitimate implementation on sparc64. >> >> I see no reason for a platform the be required to remember the boot >> cpu ID, there is nothing special about that processor generically. > > I fear we still need it and it's special due to code structure at > least. For SMP compiled kernel say callin() do change its behaviour > depending on which cpu it's called. > > Also iy seems a differ techhique used to find out on which cpu > the code is running: there is smp_processor_id() == 0 and raw version > and boot_cpu_id and cpu == 0, so having one general boot_cpu_id() would > be more clear (though we will need to clean code up then :) > > So plain hard_smp_processor_id() wouldn't help since it doesn't > say if this is a boot cpu or not. > >> And if we do need it generically, it's available there as >> hard_smp_processor_id() when start_kernel() is called. So init/main.c >> could remember that value in an __initdata annotated static variable. >> >> But just using a boolean for this "did I print the bogomips message >> already?" thing seems more than sufficient. >> > > Yes. As I see Mike already pick it up. Thanks David! > > -- Cyrill
I'd like to say that, but Peter wanted it to become an inlined function return value, and there are too many references in too many arches to a scalar value, so that moves it out of the scope of this patch set.
Thanks, Mike
| |