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

[Arnd Bergmann]

On Wednesday 18 January 2006 06:55, Milton Miller wrote:
> 1) properties (files) should be 0444 not 555
> 2) directories should be S_IFDIR not S_IFREG (create_dir)

right. both are simple copy-paste bugs

> 3) this missed one of the requirements,
>    namely that it create inodes and dentries on the fly,
>    which precludes simple_readdir

yes, that was intentional. I have no idea how to do that, so
I wrote down all that I know about for someone else to start from.

> 4) it doesn't have an api to add or remove files, which is necessary
>    because of 3 above.

I think it's an unrelated problem, but you're right.

> Ok so what should the inode number be ?
> 
> 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?

Do we need the inode number to be meaningful at all? libfs makes sure
it's unique, I think that should be enough for us.

> 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.

As long as an inode exists, it needs to hold a counted reference on the
object it represents, there should not be any doubt about that. The simple
fs prototype I posted needs the reference counts for every device node
to be held all the time because the inodes are persistant, that is the
design limitation you mentioned as 3). I forgot to give up the reference
count on delete_inode() and on failure in the init path, which is an
implementation bug.

We have several types of objects that we need to maintain, the question
is which of them can be easily regenerated and which ones can remain
in memory.

On my power mac, I estimate this much stuff in the device tree:

140 device nodes
1456 properties
1596 inodes
1876 dentries (each node also has a '..' and a '.' dentry)

931840 bytes in struct inode for properties
89600  bytes in struct inode for device nodes
361088 bytes in struct dentry for properties
104160 bytes in struct dentry for device nodes
46592  bytes in struct property
2240   bytes in struct device_node
19090  bytes in property names
212633 bytes in property data

From the memory consumption perspective, it would be most
beneficial to have the inodes for the properties created
on the fly, and we could do the same their dentries without
getting overly complicated. That is the same that is now done
in sysfs, iirc.

it would also be convenient to merge the inode struct with
device_node struct as a simplification, but the properties
would still need separate inodes that are never cached.

oh, and another bug that I found:
6) the recursive function to create the directory entries is never called,
   so the file system will only have a root entry right now.

	Arnd <><