Re: [PATCH] Open Firmware device tree virtual filesystem

On Sun, 2006-12-31 at 19:37 -0800, David Kahn wrote:
Folks,

If we reused the current code in fs/proc/proc_devtree.c
and re-wrote the underlying of_* routines for i386 only,
(in the hope of removing the complexity not needed for
this implementation) would that be an acceptable
implementation?

In other words, the of_* routines continue to define the
interface between kernel and the firmware/OS
layer. Although that code in proc_devtree.c defining
the functions duplicate_name() and fixup_name() is still
troubling to me.

The main problem with the current powerpc interface to the device-tree
(though as I said earlier, it's very handy for drivers) is that
get_property() doesn't take a buffer pointer. Thus, it's not very
suitable for an interface that involves calling into OF to retreive the
properties. It's really an interface designed around the idea that the
tree is in kernel memory, and the lifetime of the properties is tied to
the lifetime of the node.

IMHO, the directory entries in the filesystem
should be in the form "node-name@unit-address" (eg: /pci@1f,0,
"pci" is the node name, "@" is the separator character defined
by IEEE 1275, and "1f,0" is the unit-address,
which are always guaranteed to be unique.

They should be. The problem is buggy OF implementations. For example,
both IBM and Apple OFs have the nasty habit of having under the CPU
nodes an "l2-cache" node with no unit-address -and- a property with the
same name (which contains just a phandle to that l2-cache node btw).
There are other examples too (some pmacs have a duplicate i2c bus with
some one of the copies containing only a subset of the devices)

In general, we don't fabricate the @unit-address part, we use OF's own
package-to-path (unlike sparc which I think doesn't always have that
method), and thus we have to deal with implementations that return no
unit-address or duplicate names.

It's
not possible to have two ambiguously fully qualified nodes in the OFW
device tree, otherwise you would never be able to select
a specific one by name.

Well, it happens to be the case though. The code is to work around that.
A normal bug-free tree should never trigger the workarounds.

Ben.


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

Relevant Pages

  • Re: Template method pattern in Java ???
    ... > only caveats being that contracts may refer to other routines and it ... Perhaps we need two kinds of interface: ... > also allows for the inheritance of non-purely abstract classes. ... This is different in Java ...
    (comp.object)
  • Re: Template method pattern in Java ???
    ... > only caveats being that contracts may refer to other routines and it ... Perhaps we need two kinds of interface: ... > also allows for the inheritance of non-purely abstract classes. ... This is different in Java ...
    (comp.lang.java.programmer)
  • Re: Template method pattern in Java ???
    ... > only caveats being that contracts may refer to other routines and it ... Perhaps we need two kinds of interface: ... > also allows for the inheritance of non-purely abstract classes. ... This is different in Java ...
    (comp.lang.java.help)
  • Re: [patch 0/8] Nesting class_device patches that actually work
    ... you give one of your "subclass devices" an interface, ... Take a step back and look what a kernel interface is about. ... device tree by following the "device" symlink from sysfs to get a unified tree ... the hierarchy is not a reason not to be able to walk up the chain and change ...
    (Linux-Kernel)
  • Re: Template method pattern in Java ???
    ... >> world tends to call a purely abstract or purely deferred class. ... The contents of the routines are never disclosed, ... The client, and that's who we're writing the class ... doesn't see anything but the interface. ...
    (comp.lang.java.programmer)