From: Michal Ostrowski <mostrows@watson.ibm.com>
To: Matthew McClintock <msm@freescale.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.
Date: Wed, 31 May 2006 17:04:36 -0400 [thread overview]
Message-ID: <1149109476.6507.115.camel@brick> (raw)
In-Reply-To: <1149107718.8379.48.camel@localhost.localdomain>
On Wed, 2006-05-31 at 15:35 -0500, Matthew McClintock wrote:
> On Wed, 2006-05-31 at 16:26 -0400, Michal Ostrowski wrote:
> > I've had some experience with trying to edit existing OF trees (i.e.
> > take a G5 OF tree and alter it to reflect the fact that the OS has a
> > hypervisor between it and the HW). It's not a pleasant experience.
> >
> > Thus for OF based systems I'd be very wary of trying to edit the OF
> > tree
> > in arbitrary ways prior to Linux seeing it.
>
> Out of curiosity what was hard about it?
Well, suppose that you want to remove a particular device from an OF
tree. At what point are you certain that you've completely removed all
references to it?
I've always been concerned that there are some properties remaining in
the tree that may refer to the node I am removing (resulting in an
inconsistent tree). If you're working with one particular FW provider
then you may come up with code that does it right, but such code may not
necessarily catch all the extensions provided by another FW provider.
I've found Apple and IBM FW like to do things in different ways. In
particular IBM FW likes to add "ibm,*" properties and you'd have to know
the meaning of all such properties to ensure you've caught all
references to the device you're pruning.
Like with most things, getting a solution to solve your immediate
problem is easy; a perfect, general solution is much, much more
difficult.
(Granted, some things, such as adding a new "memory" node are pretty
easy to do.)
> Also it is worth mentioning
> some systems don't have to privilege of having a OF tree ready to go by
> the time Linux starts.
For such systems I think the right approach is to provide a
DTC-generated OF tree (provided that one ensures that we don't skip
important parts of prom_init.c).
--
Michal Ostrowski <mostrows@watson.ibm.com>
next prev parent reply other threads:[~2006-05-31 21:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-30 2:01 [PATCH] Provide mechanism for editing builtin command-line in zImage binary mostrows
2006-05-30 2:27 ` Michal Ostrowski
2006-05-30 20:41 ` Mark A. Greer
2006-05-30 21:12 ` Michal Ostrowski
2006-05-31 20:04 ` Mark A. Greer
2006-05-31 20:26 ` Michal Ostrowski
2006-05-31 20:35 ` Matthew McClintock
2006-05-31 21:04 ` Michal Ostrowski [this message]
2006-06-09 9:47 ` Paul Mackerras
2006-06-09 13:06 ` [PATCH] Editable kernel " mostrows
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=1149109476.6507.115.camel@brick \
--to=mostrows@watson.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=msm@freescale.com \
/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).