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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
