lkml.org 
[lkml]   [2006]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.17-rc1-mm1: KEXEC became SMP-only
Andrew Morton wrote:
> Zachary Amsden <zach@vmware.com> wrote:
>
>> Andrew Morton wrote:
>>
>>>> struct subarch_hooks subarch_hook_vector = {
>>>> .machine_power_off = machine_power_off,
>>>> .machine_halt = machine_halt,
>>>> .machine_irq_setup = machine_irq_setup,
>>>> .machine_subarch_setup = machine_subarch_probe
>>>> ...
>>>> };
>>>>
>>>> And machine_subarch_probe can dynamically change this vector if it
>>>> confirms that the platform is appropriate?
>>>>
>>>>
>>> I don't recall anyone expressing any desire for the ability to set these
>>> things at runtime. Unless there is such a requirement I'd suggest that the
>>> best way to address Eric's point is to simply rename the relevant functions
>>> from foo() to subarch_foo().
>>>
>>>
>> Avoiding the runtime assignment isn't possible if you want a generic
>> subarch that truly can run on multiple different platforms.
>>
>
> Well as I said - I haven't seen any requirement for this expressed. That
> doesn't mean that such a requirements doesn't exist, of course.
>
>
>> I prefer runtime assignment not for this reason, but simply because it
>> also eliminates two artifacts:
>>
>> 1) You can add new subarch hooks without breaking every other
>> sub-architecture
>>
>
> Is that useful? If you need a new subarch_bar() then
>
> a) Implement it in the subarch which needs it
> b) Implement an attribute(weak) stub in a new subarch-stubs.c
> c) call it.
>
> That's a little more costly than a static inline stub, but not much. Are
> there likely to be any subarch calls which are a) called frequently and b)
> not required on some subarchs?
>

No, most of these are one time init calls. The problem before was the
default subarch couldn't define weak symbols, since setup.c was in the
subarch itself and not in arch/i386/kernel. Do weak symbols work with
all tool chains?

>
>> 2) You don't need #ifdef SUBARCH_FUNC_FOO goo to do this (renaming
>> voyager_halt -> default)
>>
>
> Why would one need that? Isn't it simply a matter of renaming
> machine_halt() to subarch_machine_halt() everywhere?
>

No - if you rename machine_halt to subarch_machine_halt, you again can't
add a new subarch interface without changing all subarchitectures. If I
add voyager_smp_bless_voyage(), I now need to add #define
visws_smp_bless_voyage default_smp_bless_voyage, ... or did you mean
subarch_machine_halt literally?

> I'm just looking for the simplest option here. Eric has identified a code
> maintainability problem - it'd be good to fix that, but we shouldn't add
> runtime cost/complexity unless we actually gain something from it.
>

I think weak symbols are the best approach, if they indeed work with all
tool chains.

Zach
-
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/

\
 
 \ /
  Last update: 2006-04-05 00:40    [W:0.086 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site