[PATCH] Open Firmware device tree virtual filesystem

Benjamin Herrenschmidt benh at kernel.crashing.org
Tue Jan 2 15:48:02 EST 2007


On Tue, 2007-01-02 at 10:11 -1000, Mitch Bradley wrote:
> 
> > We could of course have the interface work either on a copy of the tree
> > or on a real OF (though that means changing things like get_property on
> > powerpc and fixing the gazillions of users) but I tend to think that
> > working on a copy always is more efficient.
> >
> >   
> The patch that I posted creates a copy in the virtual filesystem 
> domain.  So the efficiency issue is moot.
> 
> The filesystem domain copy is smaller than the in-memory tree, as it 
> omits a lot of unnecessary fields.

"a lot" ? Hrm... et me see... a device-node contains the pointers for
the tree structure and the property list ...

What other fields ? We do have indeed a void * on powerpc which is handy
for the PCI code in there but I might get rid of it at one point and we
have a copy of the phandle which is useful as soon as you try to parse
things like the interrupt-tree.

Now, you can have that, and then have a filesystem capable of
instanciating dentries & inodes on the fly based on that structure (and
thus purge them on memory pressure too. In which case the footprint is
actually smaller since inodes/dentries are big, thus it's a good thing
to be able to purge them and re-create them on the fly.

I do object basically to having something that doesn't also provide
in-kernel interfaces to access the device nodes & properties. I don't
agree with the reasoning that x86 will never need it. Now, we have
currently two slightly different interfaces, on powerpc and sparc, to
access them, and that's I think we should try to converge and use the
same interface for x86.

In addition, as sparc64 also moved to an in-memory copy of the tree, I
tend to be fairly convinced that we should also move toward the same
-implementation- also based on an in-memory copy of the tree which is
more efficient (and doesn't use a significant amount of RAM).
  
Ben.




More information about the Devel mailing list