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?
> 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?
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.
-
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]
