linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: "Pavel Machek" <pavel@suse.cz>,
	"Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>
Cc: "Yasunori Goto" <ygoto@fsw.fujitsu.com>,
	<linux-kernel@vger.kernel.org>,
	"IWAMOTO Toshihiro" <iwamoto@valinux.co.jp>,
	"Hirokazu Takahashi" <taka@valinux.co.jp>,
	"Linux Hotplug Memory Support" <lhms-devel@lists.sourceforge.net>
Subject: RE: [Lhms-devel] RE: memory hotremove prototype, take 3
Date: Thu, 4 Dec 2003 12:06:02 -0800	[thread overview]
Message-ID: <B8E391BBE9FE384DAA4C5C003888BE6F4FAF0B@scsmsx401.sc.intel.com> (raw)

> > Bingo...just the perfect excuse I need to give to my manager to keep
> > a low profile while tinkering around for a long time :)
> > 
> > Okay, so I will play a wee bit more the devil's advocate as an 
> > exercise of futility, if you don't mind. Just trying to compile a 
> > (possibly incomplete) quick list of what would be needed, can you 
> > guys help me? you know way more than I do:
> > 
> > 1) the core kernel needs to be independent of physical 
> memory position
> > 1.1) same with drivers/subsystems
> > 1.2) filesystems
> > [it cannot be really incomplete because I have added all the code
> > :/]
> 
> ...and you have bad problem at any place where physical address is
> passed to the hardware. UHCI is going to be "interesting".

Which is why this hot remove project is side-stepping all
those hard problems, and just dealling with the "easy" cases
of only allocating user memory to removeable physical memory.
This is useful for large systems made up of removeable nodes
(either to physically remove a node, or to logically re-assign
a node to a different "partition" in the machine).

Anyone who wants more than this is welcome to virtualize the
base kernel, filesystems, driver code etc. to allow hot remove
of the remainder of memory not dealt with by this patch :-)

-Tony

             reply	other threads:[~2003-12-04 20:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-04 20:06 Luck, Tony [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-12-04 16:12 [Lhms-devel] RE: memory hotremove prototype, take 3 Perez-Gonzalez, Inaky
2003-12-04 10:37 Perez-Gonzalez, Inaky
2003-12-04 11:01 ` Pavel Machek
2003-12-04  4:59 Perez-Gonzalez, Inaky
2003-12-04  9:54 ` Pavel Machek
2003-12-03  5:19 Perez-Gonzalez, Inaky
2003-12-03 21:23 ` [Lhms-devel] " Yasunori Goto

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=B8E391BBE9FE384DAA4C5C003888BE6F4FAF0B@scsmsx401.sc.intel.com \
    --to=tony.luck@intel.com \
    --cc=inaky.perez-gonzalez@intel.com \
    --cc=iwamoto@valinux.co.jp \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=taka@valinux.co.jp \
    --cc=ygoto@fsw.fujitsu.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;
as well as URLs for NNTP newsgroup(s).