> As I wrote a couple of times already, it's a perfectly acceptable > approach to have "constructors" (what you call oftree-interpreter) > that > generate platform devices from the OF tree.
Yes, lots of the "glue" code could be made into some helper library. Also, while that glue code might be perceived as being "a lot of stuff", it isn't really, and it is quite simple anyway; it's just a layer that sits there to translate for the impedance mismatch of the device tree on one hand, and the kernel interfaces on the other. Because we do have such a layer, interface changes aren't a big deal; and since the device tree interface is a way flexible, mostly text-based associative array tree thing, we have none of the problems that binary firmware interfaces on other platforms have. Oh, and the Open Firmware device tree works perfectly fine across different architectures, too. >> and they often contain redundant information (like names of oftree >> nodes, which change more often than some people's panties). > > Well, they aren't supposed to :-) The problem at this point is more > due > to the fact that for things that haven't been specified by official OF > bindings, people are going all over trying to define their own and > sometimes conflicting bindings and then changing them. This is most of the "endless debate", too. Segher _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
