[PATCH] boot: find initrd location from device-tree

[David Gibson]

On Mon, Jun 18, 2007 at 02:52:12PM +0200, Segher Boessenkool wrote:
> >>> +     /* if the initrd is above 4G, its untouchable in 32 bit mode */
> >>> +     if (initrd_end <= UINT_MAX && initrd_start < initrd_end) {
> >>> +             loader_info.initrd_addr = initrd_start;
> >>> +             loader_info.initrd_size  = initrd_end - initrd_start;
> >>> +     } else {
> >>> +             printf("ignoring loader supplied initrd parameters\n");
> >>
> >> Saying why might be helpful.
> >
> > Hmm... well, that would mean seperating the && of the if; there are two
> > possible reasons. (1) this 32-bit code can't handle such large
> > addresses (in which case a 64-bit kernel may work), and (2) end is >=
> > start (which means there really isn't any data.  I suppose I could
> > reverse the sense of the if, use an else if, and make the final else
> > the good path.
> 
> "ignoring loader supplied nonsensical initrd parameters"
> 
> You do need to fix the comment, though :-)
> 
> >>> +#define _LIBC_LIMITS_H_              /* don't recurse to system's
> >> headers */
> >>> +#include <limits.h>          /* MAX_UINT, etc */
> >>> +
> >>
> >> I think it's really a bad idea to use any headers from outside the
> >> boot context here.  We're dealing with explicit sized ints, so we can
> >> safely define our own constants giving the limit values.
> >
> > As I said in the patch changelog, the only headers picked up here are
> > libgcc.
> 
> Which the kernel doesn't use.  It _should_ be fine
> nevertheless, <limits.h> is part of the "freestanding"
> headers -- why do you need to do a "libc" trick though?
> This doesn't work when not using glibc I guess?

IMO if it needs this define magic to work properly, it's not a good
idea to include it at all.  Especially since avoiding it is easy and
safe in this case.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson