--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sat, Aug 6, 2016 at 8:15 PM, Stefan Monnier <monn...@iro.umontreal.ca> wrote: >> the only big advantage of dtb files (binary compiled) is *IF* the >> decision is made to respect dtb files and treat them as inviolate >> and supported forever without needing recompiles, you stand a >> chance of being able to upgrade linux kernels *without* replacing >> the dtb file. > > That might be true when compared to some potential replacement of DTBs, > but when compared to what we had before DTBs, then the benefit is much > more clear: a single linux-image-armhf package which works for "all" > machines. Personally I don't mind changing the DTB every time I change > the kernel. Hell, that could/should be integrated with the process > which refreshes the initrd file anyway. ... are you _sure_ it's clear? :) the reason i ask that is, i'm not seeing any real difference: you still have to download the linux kernel source (to submit dtsi patches), the linux git repo is still the central location for dtsi management... unless you're happy to set up an alternative parallel repository (and compile infrastructure) for dtsi management... thus you still have to download the full git repo, you still have to compile stuff *from* that same git repo.... where's the actual benefit to having moved to dtsi, in terms of "work needed to maintain it"? i appreciate you don't *mind* changing the DTB file each time you change the kernel, but that defeats one of the very purposes *of* the DTB file. also, i don't know if you've looked in arch/arm/boot/dts but it's already alarmingly full. i appreciate that there's some includes (dtsi) but realistically over time the sharing process is going to begin to look like the selinux m4 macro includes or the openembedded infrastructure: an unintelligeable and unmaintainable dog's dinner that only a handful of people in the world can understand. anyway to get back to the original topic, there's very little that can actually shared - even with devicetree - between different devices. it's the "N product design types" times "M processors" thing. which is why i'm designing a hardware standard that's similar to how things are in the x86 world, so that we can get back to "N PLUS M" at the linux kernel level. l.
