On Fri, 2009-05-29 at 09:59 +0800, Mitch Bradley wrote: > I have an embeddable FCode interpreter that could be built into a > kernel. Perhaps it's time to resurrect that. The total size is on the > order of 50K with debugging tools included; probably more like 35K if > stripped down to just the essentials.
It's interesting... might be an option. I tend to prefer myself having the methods be properly documented by the HW designer, and implemented as C code in the kernel, for various reasons. There are pro and cons to both approaches. We could define special properties to embed f-code in the device-tree and run it that way, it's probably a more business-friendly method :-) IE. It makes it possible to completely avoid board specific code in the kernel, possibly making it feasible to run existing distributions on new HW to a certain extend by just updating those scripts. But it comes with some drawbacks too... too often, this stuff will replace good documentation, the scripts provided by the FW will be busted in subtle ways that the kernel will have to work around, and thus it can be used as a way to avoid documenting or open sourcing things and obfuscating operations. So at this stage, my personal preference goes for well defined methods named by the device tree and implemented by the kernel natively. But people are free to disagree with me on this one. Cheers, Ben. _______________________________________________ devicetree-discuss mailing list [email protected] https://ozlabs.org/mailman/listinfo/devicetree-discuss
