[PATCH 2/5] powerpc: proc_device_tree remove and update functions

Benjamin Herrenschmidt benh at kernel.crashing.org
Thu Jan 12 10:01:59 EST 2006


On Wed, 2006-01-11 at 16:57 -0600, Dave C Boutcher wrote:
> On Thu, Jan 12, 2006 at 09:43:20AM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2006-01-11 at 22:32 +0000, Arnd Bergmann wrote:
> > > On Wednesday 11 January 2006 21:50, Benjamin Herrenschmidt wrote:
> > > > I think we should move to a filesystem instead. It should be fairly
> > > > trivial (look at sun's openpromfs for example)
> > > 
> > > openpromfs predates most of libfs, which means it is a lot more
> > > complicated than necessary already, and it doesn't fit the powerpc
> > > representation of device_node very well.
> > 
> > Yeah, well, it was just an example ;) In fact, if you think it's too
> > complicated, then what is simple ? :) (openpromfs looks trivial enough).
> > 
> > One of the big thing we want is to stop eating loads of memory on
> > machines with gazillion nodes (typically big memory machines have
> > gazillion of /memory@* nodes) among others. We want dentries & inodes to
> > be created on the fly and purged automatically.
> 
> Actually, from just having swam around in the code for a while, I think
> the procfs part is less problematic than the way we deal with the device
> tree in the kernel.  The whole "get_property() returning a no-lifetime
> pointer to some data" part is more of an architecture issue than the
> userland filesystem part.  But changing that is going to be a mess.

Agreed, it was never meant to add/remove properties, thus the lifetime
of properties was based on the lifetime of nodes...

Also, there are issues with node addition/removal fs. the iterators too.
If you iterate, at one point, you hold a reference to node A which
contains a next pointer to node B. Somebody removes node B behind your
back, then you try to iterate for the next node -> kaboom.

Similar problem all over the kernel with the lists, we probably need a
real iterator objects _or_ make global rwsem that must be taken around
iterations (and taken for write around modifications to the tree
structure).

Ben.




More information about the Linuxppc64-dev mailing list