On Mon, Nov 18, 2013 at 03:46:32PM -0700, Stephen Warren wrote: > Again, the point is not that it's hard to write the script. As you > demonstrated, it's easy. The problem is that then, everybody has to do > something different for Tegra, forever. No matter how small the actual > cost of doing it is, it's still non-scalable to require that everyone > know about this special case. I'm not convinced the issue would be > isolated to Tegra either. That's why there's the facility to allow an override to the script, just like there's the facility to override the default script when running "make install". The script which the kernel uses is just a template for what kernel developers expect to be the common case. That's not necessarily what most distros do. In fact, most distros today provide their own installation script which gets run automatically when you do "make install" which copies the kernel and then rebuilds an initramfs with everything appropriate for that kernel inside. Even the distro script can be overridden with a script in ~/bin by the user running "make install" (which therefore doesn't even have to be root if installing it into a location accessible by the user.) This is really no different. If the as-supplied-by-the-kernel script doesn't fit your needs, you are free to override it. What this gives us is the facility for distros to _sanely_ hook into the kernel build process to obtain the DT files if they so wish. As for renaming the files from what we have in the kernel, I'd say... why bother. What if we have two DT blobs with the same compatible string (which is not unlikely when you have two configurations for a platform)? I'd recommend keeping the names in the kernel tree when installing. If a distro needs to find the compatible string, then that's a bit of parsing they should do. Otherwise, we lose the ability to tell users "you need this DT blob file called X" because X will depend whether it's been installed or not. And in some cases where getting the wrong DT blob could end up quite literally destroying your hardware (eg, by setting an LDO regulator to bypass mode), it's extremely important that anything here is _simple_ and doesn't involve lots of indirection. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
