From: Rusty Russell <rusty@rustcorp.com.au>
To: Andries.Brouwer@cwi.nl
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [PATCH] setup_per_cpu_areas in 2.5.8pre3
Date: Tue, 16 Apr 2002 22:48:56 +1000 [thread overview]
Message-ID: <20020416224856.538d3e65.rusty@rustcorp.com.au> (raw)
In-Reply-To: <UTC200204142115.VAA627059.aeb@cwi.nl>
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
next prev parent reply other threads:[~2002-04-17 2:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-14 21:15 [PATCH] setup_per_cpu_areas in 2.5.8pre3 Andries.Brouwer
2002-04-16 12:48 ` Rusty Russell [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-04-17 8:24 Andries.Brouwer
2002-04-17 15:11 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020416224856.538d3e65.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox