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

[Milton Miller]

On Jan 18, 2006, at 8:20 AM, Arnd Bergmann wrote:

> On Wednesday 18 January 2006 06:55, Milton Miller wrote:
>> 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.

Unfornately I think that drives back up into the fs, since libfs
no longer works.

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

Well, if the fs were to read the tree then we only need calls to clear 
references to the nodes.  Since its static ...

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

If we stick to simple always in memory then that would be enough.  But 
if we go to dynamic, then the numbers will change under us (ok, fat may 
be similar).

inode numbers are unsigned long in the kernel, so to work on 32 bit 
platforms we have to divide that space between properties and nodes.

phandles are also 32 bits, so this becomes problematic if we allow 
adding nodes on 32 bit platforms.

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

I think it should be easy to create inodes on the fly for device nodes. 
   The hard part will be assigning the inode number, and maybe finding 
the dentry for removal.    I'll see if I find time to try something 
here.  Maybe just add an inode number to the property struct.

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

> 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.
I don't think this will be necessary, and prevents us from reading
nodes dynamically to save space.

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

Hey.  Your seperating the root inode creation into a seperate function 
made me miss this one.

milton