Re: [PATCH 04/11] x86: cleanup remaining cpumask_t ops in smpbootcode

From: Mike Travis
Date: Tue Jan 06 2009 - 09:02:19 EST


Jaswinder Singh Rajput wrote:
> Hello Mike,
>
> On Sun, Jan 4, 2009 at 6:48 PM, Mike Travis <travis@xxxxxxx> wrote:
>> --- linux-2.6-for-ingo.orig/arch/x86/include/asm/smp.h
>> +++ linux-2.6-for-ingo/arch/x86/include/asm/smp.h
>> @@ -18,9 +18,26 @@
>> #include <asm/pda.h>
>> #include <asm/thread_info.h>
>>
>> +#ifdef CONFIG_X86_64
>> +
>> +extern cpumask_var_t cpu_callin_mask;
>> +extern cpumask_var_t cpu_callout_mask;
>> +extern cpumask_var_t cpu_initialized_mask;
>> +extern cpumask_var_t cpu_sibling_setup_mask;
>> +
>> +#else /* CONFIG_X86_32 */
>> +
>> +extern cpumask_t cpu_callin_map;
>
>
> I am not able to understand, why you choose asm/smp.h
>
> You know that asm/smp.h should only be included for CONFIG_SMP

Hi Jaswinder,

I'll look closer but I had assumed that these masks would not be
used for UP configurations (it did not get any compile errors
with the allnoconfig). In fact, any access to these masks for
UP would be unnecessary since there are no callouts, the boot
cpu is assumed initialized, and it has no siblings. So the
masks are specific to SMP.

But as I said, I'll verify this.

Thanks,
Mike
>
> ----- linux/smp.h -----
> #ifdef CONFIG_SMP
>
> #include <asm/smp.h>
>
> #endif /* !SMP */
>
> -----------------------
>
> If someday this will happen:
>
> ----- asm/smp.h -----
> #ifndef _ASM_X86_SMP_H
> #define _ASM_X86_SMP_H
> #ifndef __ASSEMBLY__
> #ifdef CONFIG_SMP
> ...
> #else /* CONFIG_SMP */
> #error "Including wrong file, why you need smp.h for uniprocesor"
> #endif /* CONFIG_SMP */
> #endif /* __ASSEMBLY__ */
> #endif /* _ASM_X86_SMP_H */
>
> -----------------------
>
> Then ;-)
>
> Are you planning to make some new file for this or you think some other file will be suitable for this.
>
> If you have some future plans, please let me know.
>
> Thanks
> --
> JSR

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/