WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: [XenPPC] [PATCH] Move lots of memory logic earlier

To: Hollis Blanchard <hollisb@xxxxxxxxxx>
Subject: Re: [XenPPC] [PATCH] Move lots of memory logic earlier
From: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>
Date: Mon, 8 Jan 2007 18:38:32 -0500
Cc: xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 08 Jan 2007 15:38:33 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <e1ee8b26c15de7afd7de.1168293792@localhost>
List-help: <mailto:xen-ppc-devel-request@lists.xensource.com?subject=help>
List-id: Xen PPC development <xen-ppc-devel.lists.xensource.com>
List-post: <mailto:xen-ppc-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=unsubscribe>
References: <e1ee8b26c15de7afd7de.1168293792@localhost>
Sender: xen-ppc-devel-bounces@xxxxxxxxxxxxxxxxxxx
I disagree with what this patch does.


On Jan 8, 2007, at 4:03 PM, Hollis Blanchard wrote:

# HG changeset patch
# User Hollis Blanchard <hollisb@xxxxxxxxxx>
# Date 1168293789 21600
# Node ID e1ee8b26c15de7afd7dec2d604b00d607e1307f4
# Parent  dbc74db14a4b39d359365fcf8257216d968fa269
Move lots of memory logic earlier.
- We now require the common boot allocator has been initialized before
__start_xen(), and we use that in boot_of.c instead of managing our own.

It is far more important that we do as little as possible in boot_of, just enough to know where we are and instantiate any parts of memory that need it. When we are booted with a flattened devtree (via kexec, or some other loader), we will never call into boot_of.c. The custom boot_of allocator is trivial and allows for simple tracking of available memory.

  Removing our custom allocator is important to simplify the upcoming
  multiboot2 conversion.

how?

- We also handle arbitrary-sized properties now, instead of
  probably-large-enough fixed-sized buffers.

this is fine by me, I'm a big fan of alloca()!
However, you use:
         proplen = of_getprop(child, string, NULL, 0);
when
         proplen = of_getproplen(child, string);

Is sufficient and defined and used already in this file.


- This will also be needed to support non-Open Firmware systems (though the
  firmware-specific interface was not the focus of this patch).

But what is there is designed with non-OF in mind.
IMHO this is a step backwards.

-JX




_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel