[OpenBIOS] [PATCH] RFC: Change ofmem_common.c to set memory translation properties by reference

Blue Swirl blauwirbel at gmail.com
Sat Oct 16 18:40:49 CEST 2010

On Sat, Oct 16, 2010 at 3:18 PM, Andreas Färber <andreas.faerber at web.de> wrote:
> Mark,
> Am 14.10.2010 um 22:32 schrieb Mark Cave-Ayland:
>> The attached patch changes OFMEM so that instead of allocating new space
>> within the Forth dictionary every time the /memory and /virtual-memory
>> available/translations nodes are updated, we simply change the property to
>> point directly to a static buffer. This has the effect of saving substantial
>> amounts of memory during OpenSolaris 10 boot (in fact the final dictionary
>> size after boot is now < 256K once again).
>> Blue/Andreas: please could you take a look at this patch and make sure it
>> doesn't break anything in your SPARC64/PPC tests?
> It looks as if none of us actually tested or ack'ed it yet, all answers were
> about sparc progress and devices only...
> Me for one couldn't save your inline patch and my mailer is known to cause
> whitespace damage, and git-am wasn't able to handle the mbox file since your
> SVN diff is missing the a/ directory level expected by Git.
> If you're asking for comments from us, please be more patient. I'm still
> playing with Blue's slightly older libgcc patch, and some trivial ones of
> mine (e.g., CONFIG_RTAS or wrong return) are awaiting review/committing
> longer than yours. Please at least let us know in advance how long you're
> gonna wait, so that we have a chance to send in incomplete review comments
> even if still untested.

I'll give them a spin.

> I like the general optimization idea, but I found one typo s/fix/fit/ and I
> was wondering whether the property setting function really needs to live
> inside ofmem_common.c or whether we might want to make set_property_nocopy()
> out of it for general use.
> I also had some style questions related to the inconsistent use of spacing
> inside braces. Some ppc code even has a wild mix of tabs and 8 spaces, which
> is unfortunate when many other projects including QEMU use an indentation of
> 4. We're lacking a CODING_STYLE document imo, to look up which way it's
> supposed to be.

I'd vote for QEMU style because of common developer base and even
small amount of shared code.

More information about the OpenBIOS mailing list