WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

[XenPPC] Re: [RFC] consolidated libdt proposal

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


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel