Messages in this thread | | | Date | Fri, 10 Apr 2009 00:00:11 +0400 | From | Cyrill Gorcunov <> | Subject | Re: [PATCH] x86,apic: Checking kernel option before detect_init_APIC() |
| |
[Rakib Mullick - Thu, Apr 09, 2009 at 11:08:43AM +0600] | On Wed, Apr 8, 2009 at 8:50 PM, Ingo Molnar <mingo@elte.hu> wrote: | > | > * Rakib Mullick <rakib.mullick@gmail.com> wrote: | > | > Hm, are you sure this is a cleanup only? (i.e. no side-effects) | My quick review over code, i don't think there's any.Unless I'm not | missing anything. Kernel option has been passed when before kernel | starts, so I think it's safe.
Hi Rakib,
yes, disable_apic early parameter handled earlier then init_apic_mappings is being called but we could reach disable_apic=1 with not only as kernel option but as result of acpi_mps_check for example (which is called earlier then init_apic_mappings though). So this snippet is safe I believe.
| > | > Also, even if it's a pure cleanup, wouldnt it be even cleaner to | > propagate this check into detect_init_APIC() - and thus get rid of | > the open-coded disable_apic check altogether?
In point! We do same fasion check in APIC_init_uniprocessor
| Yes, could be. How we'll understand that whether apic has been | disabled from kernel option or not (if we requires later on)?
AFAIS, as only we set disable_apic=1 from kernel option (or other ways) we clear X86_FEATURE_APIC likewise. So I don't see easy way to distinguish the reason why apic is disabled. But to be precise APIC_init_uniprocessor print us some info.
So I'm for Ingo's idea!
| | Rakib | > | > Ingo | > | Cyrill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |