Re: 2.6.17-rc1-mm1: KEXEC became SMP-only

[Zachary Amsden <zach@vmware.com>]

Eric W. Biederman wrote:
> Adrian Bunk <bunk@stusta.de> writes:
>
>   
>> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>>     
>>> ...
>>> Changes since 2.6.16-mm2:
>>> ...
>>> +x86-clean-up-subarch-definitions.patch
>>> ...
>>>  x86 updates.
>>> ...
>>>       
>> The following looks bogus:
>>     
>
> It is. 
>
>   
>>  config KEXEC
>>         bool "kexec system call (EXPERIMENTAL)"
>> -       depends on EXPERIMENTAL
>> +       depends on EXPERIMENTAL && (!X86_VOYAGER && SMP)
>>
>> The dependencies do now say that KEXEC is only offered for machines that 
>> are _both_ non-Voyager and SMP.
>>
>> Is the problem you wanted to express that a non-SMP Voyager config 
>> didn't compile?
>>
>> AFAIR I recently sent a patch disallowing non-SMP Voyager configurations 
>> that wasn't yet applied.
>>     
>
> I think this cleanup patch is even going in the wrong direction.  The
> subarch code right now is a real pain because it is never clear when
> you are calling a function with multiple definitions.  Which makes it
> really easy to break.
>   
> If we are going to refactor this can we please move in the direction
> of a machine vector like alpha, ppc, and arm.  I don't see the current
> this cleanup making it any easier to tell there is code in a subarch.
>   

No, this cleanup only eliminates the need to duplicate redundant code.   
How does a machine vector make it any harder to break?  You still have a 
function with multiple definitions.  Duplicating code makes things 
really easy to break - twice.