On 3/19/2015 12:32 PM, Russell King - ARM Linux wrote: > On Thu, Mar 19, 2015 at 12:01:42PM -0700, Frank Rowand wrote: >> On 3/19/2015 11:41 AM, Russell King - ARM Linux wrote: >> What??? Why would we ever accept code that tested the dtb version >> instead of the compatible strings and properties in device nodes? >> The dtb version is a meaningless number just like the kernel version >> number in /proc/version is a meaningless number. It starts at 1 (and >> can be reset to 1 anytime the person controlling the build environment >> chooses to for any random reason). The dtb version number only makes >> sense in a local context to check which build of an object actually >> got onto the target. > > I think you need to learn a lesson here. I rotfled at your "just like > the kernel version number" comment, because we already have code in the > kernel to map 3.x and 4.x kernels to a 2.60.x number because userspace > breaks with 3.x and 4.x version numbers. I am aware of that and totally agree that it is on point. > > I'm quite sure that someone made the exact same argument about kernel > version numbers that you're making above about versioning dtb stuff. > > At the end of the day, if userspace starts abusing an API that we've > provided in good faith, and we change something such as the version > information which results in userspace breaking - even if userspace is > doing something that's wrong according to how we've defined it, it's > still our problem to fix. No userspace regressions when upgrading. > That's the rule. And I totally agree with that. > > Don't bother trying to argue against this - you can't. We will not accept > any argument (no matter how valid) which will result in userspace breaking > upon an upgrade. No argument. But I am not arguing for that. > > You must be *absolutely* *sure* that you want to export this information, > and that you are absolutely happy with the consequences which would occur > should userspace then start using this information in a way which you did > not intend, which could very well block you from ever being able to change > the version number from a prescribed "this version number makes userspace > work" value. I understand the concern you are expressing. And I agree it is an issue to be concerned about and not dismissed. But I also think that the concern is mis-characterizing the "DTB version". To pick on the example in patch 0, an analogous Linux version is "#5" (not "4.0.0"): Linux version 4.0.0-rc4-dirty (frank@buildhost) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #5 SMP PREEMPT Wed Mar 18 20:04:48 PDT 2015 and the proposed DTB version is "#4": DTB version 4.0.0-rc4-dirty (frank@buildhost) (DTC 1.4.0-dirty) #4 Wed Mar 18 20:04:11 PDT 2015 I don't think the concern holds for "#5" and "#4". I will concede that there is something unique in the proposed DTB version - the source code system commit version number (in this example "4.0.0-rc4-dirty" from git). -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
