RE: [2.6.6 PATCH] Exposing EFI memory map

Dave Hansen
2004-05-06T18:57:30Z

cc'ing lhms list as well, as this has diverged a bit...

On Thu, 2004-05-06 at 11:47, Tolentino, Matthew E wrote:
> > On Thu, 2004-05-06 at 09:25, Sourav Sen wrote:
> > > From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> > > Why not also update the efi memory table on a hotplug :-)
> >
> > That's actually what ppc64 does. But, they do it via /proc (not even
> > from inside the kernel). I'm not very fond of that solution :)
>
> Interesting. What does ppc64 do with the memmap after that?

This doesn't even concern mem_map yet. The userspace ppc64 hotplug
tools actually write into the "OpenFirmware" tree from userspace, after
a hotplug happens. This is partly because all of the ppc64 hotplug
operations happen in userspace as it stands now.

> So, allocate the page structs which constitute the new memmap, set up
> the nonlinear sections, and then wait for hotplug events in order to
> clear the appropriate bits in the pages for a given range? Is that
> what you're thinking?

Actually, I was thinking that we'd just allocate the kobjects, and note
the presence of the memory in the nonlinear phys_section table. Then,
when we online it, we can decide where it's mapped, what zone to put it
in, and where to get the mem_map space from. I think that approach
gives the best flexibility.

-- Dave