Re: [PATCH] setup_per_cpu_areas in 2.5.8pre3

Rusty Russell (rusty@rustcorp.com.au)
Tue, 16 Apr 2002 22:48:56 +1000


On Sun, 14 Apr 2002 21:15:29 GMT
Andries.Brouwer@cwi.nl wrote:

>
> Now that I am writing anyway, one of the changes I needed
> to compile 2.5.8pre3 is the following.

Yeah, better patch below (__GENERIC_PER_CPU implies SMP anyway).

> Of course the real fix is to remove the #ifdef's,
> maybe using a weak symbol instead, or some other construction
> that defines an empty default that can be replaced by an actual
> routine.

Not unless you make it as readable as the current code. Having magic
appearing functions sounds cool, but beware that the cure might be
worse than the disease.

Yes, I know this patch looks like I'm moving smp_init(), but really
it's moving the #ifdef __GENERIC_PER_CPU bit past the SMP #endif.

Rusty.

-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.8/init/main.c working-2.5.8-percpu/init/main.c
--- linux-2.5.8/init/main.c	Mon Apr 15 11:47:50 2002
+++ working-2.5.8-percpu/init/main.c	Tue Apr 16 21:11:50 2002
@@ -274,6 +274,18 @@
 
 #else
 
+/* Called by boot processor to activate the rest. */
+static void __init smp_init(void)
+{
+	/* Get other processors into their bootup holding patterns. */
+	smp_boot_cpus();
+
+	smp_threads_ready=1;
+	smp_commence();
+}
+
+#endif
+
 #ifdef __GENERIC_PER_CPU
 unsigned long __per_cpu_offset[NR_CPUS];
 
@@ -301,18 +313,6 @@
 {
 }
 #endif /* !__GENERIC_PER_CPU */
-
-/* Called by boot processor to activate the rest. */
-static void __init smp_init(void)
-{
-	/* Get other processors into their bootup holding patterns. */
-	smp_boot_cpus();
-
-	smp_threads_ready=1;
-	smp_commence();
-}
-
-#endif
 
 /*
  * We need to finalize in a non-__init function or else race conditions

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