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: <20150319193225.GH8656@n2100.arm.linux.org.uk>
Date:	Thu, 19 Mar 2015 19:32:25 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Frank Rowand <frowand.list@...il.com>
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 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'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.

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.

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.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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/