[PATCH 0/5] powerpc: add device tree property updates

Benjamin Herrenschmidt benh at kernel.crashing.org
Thu Jan 19 09:56:38 EST 2006


O
> 1) properties (files) should be 0444 not 555
> 2) directories should be S_IFDIR not S_IFREG (create_dir)
> 3) this missed one of the requirements,
>    namely that it create inodes and dentries on the fly,
>    which precludes simple_readdir
> 4) it doesn't have an api to add or remove files, which is necessary
>    because of 3 above.

I think we don't need such an API if we _really_ create them on the fly
and do dynamic allocation, which the patch doesn't do but we should. One
of the main reason for doing a filesytem is to avoid having a static
allocation of filesystem object for everything in the device-tree.

Once we have dynamic allocation, all we need is to invalidate directories
when files are added/removed. Thus a simpler API

> Ok so what should the inode number be ?

I was thinking about the phandle, but that would require creating
phandles for nodes who don't have them (BootX booting or flat tree with
only some nodes having phandles). The advantage is that it's stable
accross boots. The cons is that the creation of missing phandles is a
bit annoying as it needs to make sure it "skips" whatever phandles have
already been assigned.

> directory inodes should be the phandle .... yeah ..  now to assign all
> the others non-conflicting.   Do all the current phandle generators
> use either a memory address, offset, or small enum?

Or we could just use the pointer to struct device_node for now. That
means they become volatile between mounts reboots but that's fine. At
least at first. We can then look into the problem of maybe using
phandles.

> 5) ref counts ... i would think the node should only be refcounted
>    when the directory is open ...  (you were careful to put the root
>    but not the child nodes on failed alloc).
> 
>    Actually i guess it should be refcounted with the inode lifetime.
> 
> 
> 
> Ok, its taking more like 10-20 minutes to type this in, thinking
> of more along the way.
> 
> milton




More information about the Linuxppc64-dev mailing list