Messages in this thread | | | Date | Tue, 04 Apr 2006 10:51:43 -0700 | From | Zachary Amsden <> | Subject | Re: 2.6.17-rc1-mm1: KEXEC became SMP-only |
| |
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. - 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/
| |