From: Hollis Blanchard <hollisb@us.ibm.com>
To: "Mark A. Greer" <mgreer@mvista.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, 08 Aug 2006 13:25:10 -0500 [thread overview]
Message-ID: <1155061510.30116.197.camel@basalt.austin.ibm.com> (raw)
In-Reply-To: <20060808180408.GD6079@mag.az.mvista.com>
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? Do you have code that would be difficult to convert to
using
ft_set_prop(tree, "/node/prop", buf, buflen);
?
> > 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.
--
Hollis Blanchard
IBM Linux Technology Center
next prev parent reply other threads:[~2006-08-08 18:25 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 [this message]
2006-08-08 18:51 ` Mark A. Greer
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=1155061510.30116.197.camel@basalt.austin.ibm.com \
--to=hollisb@us.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=mgreer@mvista.com \
--cc=pantelis@embeddedalley.com \
--cc=xen-ppc-devel@lists.xensource.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).