From: David Gibson <david@gibson.dropbear.id.au>
To: Milton Miller <miltonm@bga.com>
Cc: ppcdev <linuxppc-dev@ozlabs.org>, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH 1/15] boot: find initrd location from device-tree
Date: Tue, 25 Sep 2007 13:27:05 +1000 [thread overview]
Message-ID: <20070925032705.GA2525@localhost.localdomain> (raw)
In-Reply-To: <c76a222305d08e74b878c946d4181078@bga.com>
On Mon, Sep 24, 2007 at 03:02:36AM -0500, Milton Miller wrote:
>
> On Sep 23, 2007, at 9:58 PM, David Gibson wrote:
>
> > On Fri, Sep 21, 2007 at 06:03:24PM -0500, Milton Miller wrote:
> >> Some platforms have a boot agent that can create or modify properties
> >> in
> >> the device-tree and load images into memory. Provide a helper to set
> >> loader_info used by prep_initrd().
> >>
> >> Signed-off-by: Milton Miller <miltonm@bga.com>
> >> Acked-by: David Gibson <david@gibson.dropbear.id.au>
> >
> > Hrm, despite my earlier ack, I'm going to whinge about a few nits
> > here.
> >
> >> ---
> >> re 12168
> >> rediffed types.h, offset in ops.h
> >>
> >> Index: kernel/arch/powerpc/boot/ops.h
> >> ===================================================================
> >> --- kernel.orig/arch/powerpc/boot/ops.h 2007-09-17 22:12:47.000000000
> >> -0500
> >> +++ kernel/arch/powerpc/boot/ops.h 2007-09-17 22:12:51.000000000 -0500
> >> @@ -163,6 +163,7 @@ void dt_fixup_clock(const char *path, u3
> >> void __dt_fixup_mac_addresses(u32 startindex, ...);
> >> #define dt_fixup_mac_addresses(...) \
> >> __dt_fixup_mac_addresses(0, __VA_ARGS__, NULL)
> >> +void dt_find_initrd(void);
> >>
> >>
> >> static inline void *find_node_by_linuxphandle(const u32 linuxphandle)
> >> Index: kernel/arch/powerpc/boot/types.h
> >> ===================================================================
> >> --- kernel.orig/arch/powerpc/boot/types.h 2007-09-17
> >> 22:12:47.000000000 -0500
> >> +++ kernel/arch/powerpc/boot/types.h 2007-09-17 22:12:51.000000000
> >> -0500
> >> @@ -12,6 +12,8 @@ typedef short s16;
> >> typedef int s32;
> >> typedef long long s64;
> >>
> >> +#define UINT_MAX 0xFFFFFFFF
> >
> > I actually don't like this constant - at the point you compare you
> > care, explicitly, about the value not being over 32-bits, rather than
> > whether it fits a uint, so the named constant is more misleading than
> > helpful.
>
> Arguable, I don't like counting F's or zeros in C code.
So check if (addr >> 32) is non-zero.
> It is used as the max address that the wrapper deals with, both here
> and memranges, which happens to be 32 bits.
Right and the reasons for that being the value it is are not because
it also hapeens to be the max uint *or* ulong.
> Actually it cares about overflowing the unsigned long in loader_info,
> not that the address fits in 32 bits.
>
> So it should be ULONG_MAX now (malloc and all the address code was
> changed to use unsigned long instead of unsigned int since the patch
> was written).
>
> And dt_xlate needs the same information. Its is using a hardcoded 64
> bit constant to provide the a simiar check.
>
>
> >> +
> >> #define min(x,y) ({ \
> >> typeof(x) _x = (x); \
> >> typeof(y) _y = (y); \
> >> Index: kernel/arch/powerpc/boot/devtree.c
> >> ===================================================================
> >> --- kernel.orig/arch/powerpc/boot/devtree.c 2007-09-17
> >> 22:12:47.000000000 -0500
> >> +++ kernel/arch/powerpc/boot/devtree.c 2007-09-17 22:12:51.000000000
> >> -0500
> >> @@ -1,6 +1,7 @@
> >> /*
> >> * devtree.c - convenience functions for device tree manipulation
> >> * Copyright 2007 David Gibson, IBM Corporation.
> >> + * Copyright 2007 Milton Miller, IBM Corporation.
> >> * Copyright (c) 2007 Freescale Semiconductor, Inc.
> >> *
> >> * Authors: David Gibson <david@gibson.dropbear.id.au>
> >> @@ -333,3 +334,68 @@ int dt_is_compatible(void *node, const c
> >>
> >> return 0;
> >> }
> >> +
> >> +/**
> >> + * dt_find_initrd - set loader initrd location based on existing
> >> properties
> >> + *
> >> + * finds the linux,initrd-start and linux,initrd-end properties in
> >> + * the /chosen node and sets the loader initrd fields accordingly.
> >> + *
> >> + * Use this if your loader sets the properties to allow other code to
> >> + * relocate the tree and/or cause r3 and r4 to be set on true OF
> >> + * platforms.
> >
> > I am unable to make sense of the paragraph above.
>
> The phrase "relocate the tree" should be "relocate the initrd", which
> the wrapper will do if it located below vmlinux.size. Also, r3 and r4
> need to be set when booting the kernel from a client interface with an
> initrd so it can take it into consideration when choosing the location
> to build the flat tree.
>
> How about:
>
> Filling in the loader info allows main.c to be aware of the initrd,
> meaning prep_initrd will move the initrd if it will be overwritten when
> the kernel is copied to its runtime location. In addition, if you are
> booting the kernel from a client interface instead of a flat device
> tree, this also causes r3 and r4 to be set so the kernel can avoid
> overwriting the initrd when creating the flat tree.
Clearer, but I still don't see that it says anything useful - "finds
the initrd from the devtree and does all the things that are supposed
to be done with an initrd" - which is implied in the previous
paragraph.
>
> >
> >> + */
> >> +void dt_find_initrd(void)
> >> +{
> >> + int rc;
> >> + unsigned long long initrd_start, initrd_end;
> >> + void *devp;
> >> + static const char start_prop[] = "linux,initrd-start";
> >> + static const char end_prop[] = "linux,initrd-end";
> >
> > I think these constants are more obscuring than useful.
>
> They are useful to the extent they reduce the number of source
> characters causing about 8 less line wraps. Since they are used
> multiple places, the compiler only needs to emit one copy of this byte
> sequence. Admitedly you made this point in a prior review.
The compiler is perfectly capable of folding identical string
constants.
> >> +
> >> + devp = finddevice("/chosen");
> >> + if (! devp) {
> >> + return;
> >> + }
> >
> > CodingStyle would not put { } here.
>
> Yea, nit. not sure why I have the braces there, I usually follow that
> one. And what's that space doing after !?
>
> >
> >> +
> >> + rc = getprop(devp, start_prop, &initrd_start, sizeof(initrd_start));
> >> + if (rc < 0)
> >> + return; /* not found */
> >> + /* The properties had to be 8 bytes until 2.6.22 */
> >> + if (rc == sizeof(unsigned long)) {
> >> + unsigned long tmp;
> >> + memcpy(&tmp, &initrd_start, rc);
> >> + initrd_start = tmp;
> >> + } else if (rc != sizeof(initrd_start)) { /* now they
> >> can be 4 */
> >
> > Right. 8 bytes and 4 bytes, so you should be using explicit length
> > types instead of long and long long.
>
> Ok, I guess we ahve u32 and u64 in types.h now. But there is other
> code in the wrapper that assumes its compiled 32 bit ILP.
Yes, but that's no reason to propagate the sin.
> >> + printf("unexpected length of %s in /chosen!\n\r", start_prop);
> >> + return;
> >
> > All these printf() / return stanzas add a lot of verbosity to this
> > function. Any way they can be consolidated a bit, maybe a single
> > error path that just prints the property values, so the user can
> > figure out what was wrong with them.
>
> On a prior review I got asked to split the reasons for ingoring the
> values below (the > 32 bit address from end < start cases). Admitedly
> without all the detailed errors the justification for the string
> varables is reduced.
Hrm. Well, I can't say I'm entirely convinced either way on this
one. I guess I'll think about it again once the rest is cleaned up.
--
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-09-25 3:27 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-21 23:02 [PATCH 0/15] bootwrapper: kexec and external payloads Milton Miller
2007-09-21 23:03 ` [PATCH 1/15] boot: find initrd location from device-tree Milton Miller
2007-09-24 2:58 ` David Gibson
2007-09-24 5:50 ` Rob Landley
2007-09-24 8:02 ` Milton Miller
2007-09-25 3:27 ` David Gibson [this message]
2007-09-26 5:49 ` Milton Miller
2007-09-21 23:03 ` [PATCH 2/15] boot: record header bytes in gunzip_start Milton Miller
2007-09-24 2:59 ` David Gibson
2007-09-21 23:03 ` [PATCH 3/15] boot: simplfy gunzip_finish Milton Miller
2007-09-21 23:03 ` [PATCH 4/15] bootwrapper: smp support code Milton Miller
2007-09-21 23:04 ` [PATCH 5/15] bootwrapper: occuppied memory ranges Milton Miller
2007-09-24 3:09 ` David Gibson
2007-09-24 9:33 ` Milton Miller
2007-09-21 23:04 ` [PATCH 6/15] bootwrapper: help for 64 bit cpus Milton Miller
2007-09-24 3:14 ` David Gibson
2007-09-21 23:04 ` [PATCH 7/15] bootwrapper: Add kexec callable zImage wrapper Milton Miller
2007-09-24 3:23 ` David Gibson
2007-09-21 23:05 ` [PATCH 8/15] bootwrapper: convert flatdevtree to version 16 Milton Miller
2007-09-24 3:36 ` David Gibson
2007-09-24 6:54 ` Milton Miller
2007-09-25 3:46 ` David Gibson
2007-09-26 16:19 ` Milton Miller
2007-09-27 2:45 ` David Gibson
2007-09-27 15:44 ` Milton Miller
2007-09-28 2:40 ` David Gibson
2007-09-28 15:16 ` Milton Miller
2007-10-03 5:29 ` David Gibson
2007-09-21 23:05 ` [PATCH 9/15] bootwrapper: rtas support Milton Miller
2007-09-24 3:46 ` David Gibson
2007-09-21 23:05 ` [PATCH 10/15] bootwrapper: add cpio file extraction library Milton Miller
2007-09-21 23:06 ` [PATCH 11/15] bootwrapper: allow vmlinuz to be an external payload Milton Miller
2007-09-21 23:06 ` [PATCH 12/15] bootwrapper: kexec extract vmlinux from initramfs Milton Miller
2007-09-21 23:06 ` [PATCH 13/15] bootwrapper: attach an empty vmlinux Milton Miller
2007-09-24 4:03 ` David Gibson
2007-09-21 23:08 ` [PATCH 14/15] boot: add a hook to start cpus Milton Miller
2007-09-21 23:08 ` [PATCH 15/15] bootwrapper: recheck for command line after fixups Milton Miller
2007-09-21 23:08 ` [PATCH 1/2] qemu platform, v2 Milton Miller
2007-09-22 9:55 ` Christoph Hellwig
2007-09-22 19:16 ` Rob Landley
2007-09-23 4:27 ` Paul Mackerras
2007-09-23 22:01 ` Rob Landley
2007-09-28 16:53 ` Segher Boessenkool
2007-09-28 20:14 ` Rob Landley
2007-10-01 5:33 ` David Gibson
2007-10-17 20:28 ` Grant Likely
2007-10-17 23:09 ` Rob Landley
2007-10-18 9:59 ` Matt Sealey
2007-10-18 17:19 ` Milton Miller
2007-10-18 17:29 ` Grant Likely
2007-10-19 6:28 ` Rob Landley
2007-09-24 4:00 ` David Gibson
2007-09-24 7:46 ` Christoph Hellwig
2007-09-24 9:48 ` Milton Miller
2007-09-21 23:08 ` [PATCH 2/2] qemu platform rom, v2 Milton Miller
-- strict thread matches above, loose matches on Subject: below --
2007-07-10 22:07 [PATCH 0/15] bootwrapper: support for kexec to zImage Milton Miller
2007-07-10 22:07 ` [PATCH 1/15] boot: find initrd location from device-tree Milton Miller
2007-07-19 2:10 ` 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=20070925032705.GA2525@localhost.localdomain \
--to=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).