From: David Gibson <david@gibson•dropbear.id.au>
To: Segher Boessenkool <segher@kernel•crashing.org>
Cc: ppcdev <linuxppc-dev@ozlabs•org>,
Paul Mackerras <paulus@samba•org>,
Milton Miller <miltonm@bga•com>
Subject: Re: [PATCH] boot: find initrd location from device-tree
Date: Tue, 19 Jun 2007 11:25:57 +1000 [thread overview]
Message-ID: <20070619012557.GB24530@localhost.localdomain> (raw)
In-Reply-To: <bfbd4f126c427f590198a3e50a789b0c@kernel.crashing.org>
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
next prev parent reply other threads:[~2007-06-19 1:25 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
2007-06-19 1:25 ` David Gibson [this message]
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=20070619012557.GB24530@localhost.localdomain \
--to=david@gibson$(echo .)dropbear.id.au \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=miltonm@bga$(echo .)com \
--cc=paulus@samba$(echo .)org \
--cc=segher@kernel$(echo .)crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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