On Sun, 3 Apr 2011, Andy Green wrote: > I just don't see people tweaking DT tables by package update and leaving the > kernel package unchanged, I do see wrong version DT tables getting pulled in, > bootloader environments pointing to the wrong place or NAND or default > environments coming in and causing DT load failure, and serious issues coming > from trying to manage boot.scr via package. I don't see we should want people > writing their own customized boot.scr to point the same kernel to different DT > tables, as this also is going to make bug reports nondeterministic.
In a perfect world, the DT data would be tied to the hardware and provided by the bootloader to the kernel. It would be produced by hardware vendors who would only have to describe their hardware in this OS independent abstraction without having to write any kernel code. And it would allow for an existing kernel binary that was distributed prior the availability of the hardware to boot unmodified on that hardware. This is a pretty noble goal of course. But I'm skeptical. I'm afraid that the reality is just too messy for this to be achievable, except maybe for the easy cases. And the easy cases are not worth all this trouble. But I don't care much if this is never achieved. Booting an existing binary on future hardware is not expected to work at the moment either. At least DT do provide the opportunity to force some consolidation and cleanups which is a sufficient reason already to go for it. What I fear is the situation where this mechanism designed to make things simpler would actually make them even more complicated. Because the simple fact of distributing knowledge and responsibilities across multiple entities (bootloader, DT representation, kernel) is multiplying the opportunities for bugs, version skews, and interpretation differences. A system that has to rely on externally provided data is always going to be way more vulnerable and error prone than a self contained system. I would like to be proven wrong of course. But in the mean time, I'm making sure that the DT information in the bootloader can be user replaced, or if need be simply overridden with a transparent mechanism which is to simply append the DT of your choice to the kernel image. > (It was suggested also on that lkml thread to cast DT stuff out into a module, > but that's not going to fly since the information presumably that will be part > of DT like where the mmc controller is, what mux settings for the balls are > needed, clock tree for it are in the module that you need on mmc, for example. > So it seems to me it needs to be built-in.) Forget about DT in modules. That is nonsense. I don't think having it built-in is a good idea either. In sync, yes. But if it can be loosely coupled then at least the idea of making it independent from the kernel has a chance of being tested, and when we have the ability to boot the same kernel binary on multiple hardware then in theory the kernel will be a bit smaller than if it has to carry the information for all those boards compiled in like it is the case now. Nicolas _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
