[PATCH] Open Firmware device tree virtual filesystem

[Segher Boessenkool]

>> Not the same exact thing -- using a text representation for
>> the property contents is a very different thing (and completely
>> braindead).
>
> The filesystem bit is for groveling around and getting information
> from the shell prompt, or shell scripts.  Text processing.
>
> If you want the binary bits, export it with something like
> /dev/openprom.

But we'd have to implement a tree structure on top of that.

If for doing "real" things we have to use some device file with
some helper program, we can do away with the whole filesystem
thing just as well -- *always* use that helper program.

On the PowerPC side of things, we have binary properties in
the device tree filesystem, and have a simple user space
program to make it readable as text.

> We don't generally export binary representation
> files out of /proc or /sys, in fact this rule I believe is layed
> our precisely somewhere at least in the sysfs case.

That only works for sysfs because there is the "one value
per file" rule -- something the OF device tree doesn't do,
and doesn't need to do, since it uses a well-defined binary
format.

If you *really* want (the option of) showing things as text
in the filesystem, you better make it so that there is a
one-to-one translation back to binary.  For example, what
does this mean, is it a text string or two bytes:

01.02

Yes you as a user can guess, but scripts can't (reliably).

>> Every architecture that supports the device tree filesystem,
>> initialises a "struct device_tree_ops" with a bunch of
>> pointers to functions that allow you to traverse the device
>> tree and read its properties (and maybe write properties, or
>> even delete and create new nodes.  The devtree filesystem code
>> simply calls into these functions to do the actual operations
>> on the device tree (access an in-kernel data structure, call
>> the OF, or both -- or something entirely different, who knows).
>
> That's the only key point in my opinion, any clean interface that
> sits in front of this stuff is fine as long as it encompasses
> all of the necessary operations and allows just about any
> implementation underneath.

Yeah.  And I'd like to have it as a collection of function
pointers so the arch code can put in the implementation it
needs at boot time.  Flexibility is good.


Segher