public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: "Mark A. Greer" <mgreer@mvista•com>
To: Hollis Blanchard <hollisb@us•ibm.com>
Cc: linuxppc-dev@ozlabs•org,
	Pantelis Antoniou <pantelis@embeddedalley•com>,
	linuxppc-embedded <linuxppc-embedded@ozlabs•org>,
	"xen-ppc-devel@lists•xensource.com"
	<xen-ppc-devel@lists•xensource.com>
Subject: Re: [RFC] consolidated libdt proposal
Date: Tue, 8 Aug 2006 11:51:31 -0700	[thread overview]
Message-ID: <20060808185131.GA9231@mag.az.mvista.com> (raw)
In-Reply-To: <1155061510.30116.197.camel@basalt.austin.ibm.com>

On Tue, Aug 08, 2006 at 01:25:10PM -0500, Hollis Blanchard wrote:
> On Tue, 2006-08-08 at 11:04 -0700, Mark A. Greer wrote:
> > 
> > Except for not being able to extend a property (see below),
> > I think it does meet my needs (at least as I know them today).
> 
> Great.
> 
> > However, I was hoping to keep the interfaces in the bootwrapper
> > similar to the ones used in the kernel.  To that end, I had a
> > routine to find a device node and other routines to find and modify
> > a property within that node.  I didn't notice a "finddevice" type of
> > function to find a device node.  Would you have a problem adding one?
> 
> The way property modification works now is this:
> 	p = ft_get_prop(tree, "/xen/console/interrupts", &len);
> 	if ((NULL == p) || (len != foolen))
> 		return;
> 	*p = cpu_to_be32(foo);
> (That does need to be hidden in a yet-to-be-written ft_set_prop().)
> 
> If necessary, it looks like it would be possible to modify ft_get_prop()
> to return a pointer to the beginning of the node structure, but is it
> really necessary?

No, its just a preference to have it look similar to kernel code.

> Do you have code that would be difficult to convert to
> using
> 	ft_set_prop(tree, "/node/prop", buf, buflen);
> ?

No.

> > > One limitation of the attached code is that it doesn't support changing
> > > the *size* of properties, though I don't think that would be too
> > > difficult to add if needed.
> > 
> > If we're going to allow cmdline editing in the bootwrapper, we would
> > need to extend the size of a property.  We've never really talked about
> > cmdline editing in the powerpc branch but I assume that its a good
> > thing(tm).  I know I would like to have it so, IMHO, I think we should
> > add it (and therefore require extending a property).
> 
> I agree, and it shouldn't be too much work. I'll take a look later this
> week, if nobody else has.

OK.

Mark

  reply	other threads:[~2006-08-08 18:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-19 23:05 [PATCH 3/6] bootwrapper: Add device tree ops for flattened device tree Mark A. Greer
2006-08-02 16:10 ` Tom Rini
2006-08-02 17:05   ` Mark A. Greer
2006-08-02 17:23     ` Tom Rini
2006-08-07  0:38 ` Hollis Blanchard
2006-08-07 21:58   ` [RFC] consolidated libdt proposal Hollis Blanchard
2006-08-08  5:37     ` Haren Myneni
2006-08-08  9:34       ` Pantelis Antoniou
2006-08-09  3:19         ` Haren Myneni
2006-08-08 18:04     ` Mark A. Greer
2006-08-08 18:25       ` Hollis Blanchard
2006-08-08 18:51         ` Mark A. Greer [this message]
2006-08-08 18:46     ` Matthew McClintock
2006-08-08 19:12       ` Matthew McClintock
2006-08-11 19:33         ` Jon Loeliger
2006-08-08  0:30   ` [PATCH 3/6] bootwrapper: Add device tree ops for flattened device tree Mark A. Greer
2006-09-08  3:38 ` [PATCH 3/6] bootwrapper: Add flat device tree ops glue code Mark A. Greer
  -- strict thread matches above, loose matches on Subject: below --
2006-08-10 16:51 [RFC] consolidated libdt proposal Milton Miller
2006-08-10 18:55 ` Mark A. Greer
2006-08-11  4:55   ` Milton Miller

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=20060808185131.GA9231@mag.az.mvista.com \
    --to=mgreer@mvista$(echo .)com \
    --cc=hollisb@us$(echo .)ibm.com \
    --cc=linuxppc-dev@ozlabs$(echo .)org \
    --cc=linuxppc-embedded@ozlabs$(echo .)org \
    --cc=pantelis@embeddedalley$(echo .)com \
    --cc=xen-ppc-devel@lists$(echo .)xensource.com \
    /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