linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).