mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: linux-kernel@vger.kernel.org
Cc: ralf@gnu.org, rhw@memalpha.cx, mingo@redhat.com,
	paulus@samba.org, anton@samba.org, schwidefsky@de.ibm.com,
	bh@sgi.com, davem@redhat.com, ak@suse.de, torvalds@transmeta.com
Subject: Hotplug CPU Boot Changes: BEWARE
Date: Fri, 07 Jun 2002 20:40:36 +1000	[thread overview]
Message-ID: <E17GHB3-0000gD-00@wagner.rustcorp.com.au> (raw)

Hi all (esp port maintainers),

	In writing the hotplug CPU stuff, Linus asked me to alter the
boot sequence to "plug in" CPUs.  I am shortly going to be sending
these patches to him now I have got my x86 box to boot with the
changes.

The changes are as follows:
1) Non-linear CPU support.  No more number/logical map, or
   smp_num_cpus.  This is easy to change over to.

2) The boot sequence used to be:
	smp_boot_cpus()
	smp_commence()
	start idle thread, do initfuncs...

   Now it is:
	start idle thread
	smp_prepare_cpus(int max_cpus)
		=> Probes for cpus, sets up cpu_possible() macro to work.
	do initfuncs
	For each cpu for which cpu_possible(cpu) is true:
		cpu_up(int cpunum)
	smp_cpus_done(max_cpus);

There are two ways to transition: one is to do the minimal hacks so
that the new boot code works (as per my x86 patch).  The other is to
take into account that the next stage (optional by arch) is to
actually bring cpus up and down on the fly, and hence actually write
code that will work after boot as well (as per my ppc patch).

For the patches, see:
	http://www.kernel.org/pub/linux/kernel/people/rusty

Rusty.	
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

             reply	other threads:[~2002-06-07 10:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-07 10:40 Rusty Russell [this message]
2002-06-07 14:51 ` Eric W. Biederman
2002-06-02 16:22   ` Pavel Machek
2002-06-08  1:55   ` Keith Owens
2002-06-10  7:05   ` Rusty Russell
2002-06-10 13:43     ` Eric W. Biederman

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=E17GHB3-0000gD-00@wagner.rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=ak@suse.de \
    --cc=anton@samba.org \
    --cc=bh@sgi.com \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=ralf@gnu.org \
    --cc=rhw@memalpha.cx \
    --cc=schwidefsky@de.ibm.com \
    --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

all inboxes | Powered by JetHome®