linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Milton Miller <miltonm@bga.com>
Cc: ppcdev <linuxppc-dev@ozlabs.org>,
	Paul Mackerras <paulus@samba.org>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH] boot: find initrd location from device-tree
Date: Mon, 18 Jun 2007 14:52:12 +0200	[thread overview]
Message-ID: <bfbd4f126c427f590198a3e50a789b0c@kernel.crashing.org> (raw)
In-Reply-To: <fbae4506b772f07d2a8c1d230bea82c8@bga.com>

>>> +     /* 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?


Segher

  reply	other threads:[~2007-06-18 12:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-15 18:17 [PATCH] boot: find initrd location from device-tree Milton Miller
2007-06-15 19:55 ` Scott Wood
2007-06-18  6:08   ` Milton Miller
2007-06-18 12:52     ` Segher Boessenkool [this message]
2007-06-19  1:25       ` David Gibson
2007-06-19  6:44         ` Segher Boessenkool
  -- strict thread matches above, loose matches on Subject: below --
2007-06-15 17:34 Milton Miller
2007-06-18  3:18 ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bfbd4f126c427f590198a3e50a789b0c@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=miltonm@bga.com \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).