Deprecating reserve-map in favor of properties

[Kumar Gala]

On Sep 20, 2012, at 5:10 PM, Benjamin Herrenschmidt wrote:

> Hi folks !
> 
> The reserve map is, imho, my biggest mistake when coming up with the FDT
> format.
> 
> The main problem is that it doesn't survive the transition via a real
> Open Firmware interface. There is no practical way to indicate reserved
> regions of memory accross in that case, unless you have an OS that is
> nice enough to try to keep OF alive and accomodate its advertised
> "available" properties, but that's typically not the case of Linux on
> ppc.
> 
> So I would like to propose that we add a new "better" way to convey
> reserved memory information, via properties in the tree.
> 
> I originally though of having these in the "memory" nodes themselves but
> this can be tricky on machines that have multiple nodes (ie, NUMA
> generally means a memory node per NUMA node) since the reserved regions
> can spawn accross nodes and I don't want to complicate FW life too much
> by requiring breaking them up in that case.
> 
> So what about something at the root of the tree:
> 
> reserved-ranges: An array of ranges of reserved memory
> 
> reserved-names: A list of zero terminated strings, one for each entry in
> the reserved-ranges array, providing optional "names" for the reserved
> ranges.
> 
> The idea here is that we could have well defined names (using a similar
> prefix we use for properties) such as linux,initrd, which indicates
> clearly to the kernel that the only reason that range is reserved is
> because it contains an initrd (ie, it can be freed once that's been
> extracted).
> 
> It would also be generally handy in case a reserved area is meant to be
> used by a specific driver, such as an in-memory framebuffer
> pre-initialized by the firmware. The generic memory management code
> doesn't need to know, but later on, the gfx driver can pick it up easily
> provided the name is part of the binding for that device.
> 
> Any objection ? If none, I'll cook up a patch to add support for it (at
> least on powerpc :-)
> 
> Cheers,
> Ben.

If you do this, please update the code in dtc/libfdt to construct the new nodes.  We use this in u-boot to reserve kernel, dtb, initrd, etc regions.  So would be nice to have drop in replacement code that could use same APIs if possible.

- k