Re: [PATCH] Open Firmware device tree virtual filesystem

[Segher Boessenkool <segher@kernel.crashing.org>]

> > Are you really suggesting that using a kernel copy of the
> > device tree is the correct thing to do, and the only correct
> > thing to do -- with the sole argument that "that's what the
> > current ports do"?
>
> Well, there are reasons why that's what the current ports do :-)

Sure.  It might have been a good choice for the current two ports
(probably was even, at least at that point in time the choice was
made -- doesn't mean you can't ever step back on it).

That doesn't mean it's a good choice for everything and certainly
it's not the only realistic choice for everything.

> We could of course have the interface work either on a copy of the tree
> or on a real OF

Yes.  I'd like to steer in that direction eventually.

> (though that means changing things like get_property on
> powerpc

You can keep the function name, and have it redirect through
a struct device_tree_ops or similar.

> and fixing the gazillions of users)

which isn't needed if we can manage to keep the function arguments
identical.

We also can keep the old names as compatibility accessors for
PowerPC only for a while, until everything is converted -- SPARC
can do the same then.  You can't really keep the old PowerPC names
in kernel-wide code anyway, "get_property" is a way too generic
name for that for example.

> but I tend to think that
> working on a copy always is more efficient.

In general, nothing using the device tree cares about a few
cycles extra (well, a few thousand perhaps).  The sole exception
would seem to be the filesystem; and it could easily keep a cache,
one with a global invalidate (via callback?) on any device tree
change even -- changes are infrequent, and basically non-existent
after early kernel boot.  Does any generic such cache for all
simple filesystems exist already?


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/