Andrew Morton wrote:
Zachary Amsden <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
