> > 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). The problem that Russell is describing is that regardless of the origin and intended purpose of the value, some consumer of the value will decide that some arbitrary value means something special to them (even if it does not), and when this changes thigns will break. So in that respect, it doesn't matter where the value came from or what you intend it to mean; it will almost certainly be abused. We try to avoid introducing fragile interfaces like these. Mark. -- 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
