linux-kernel - Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <550B3549.1030808@gmail.com>
Date:	Thu, 19 Mar 2015 13:44:57 -0700
From:	Frank Rowand <frowand.list@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
CC:	Rob Herring <robherring2@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Grant Likely <grant.likely@...aro.org>,
	Michal Marek <mmarek@...e.cz>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	linux-kbuild@...r.kernel.org,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

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@...ldhost) (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@...ldhost) (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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/