linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: frowand.list@gmail.com (Frank Rowand)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding
Date: Thu, 19 Mar 2015 13:44:57 -0700	[thread overview]
Message-ID: <550B3549.1030808@gmail.com> (raw)
In-Reply-To: <20150319193225.GH8656@n2100.arm.linux.org.uk>

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 at 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 at 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).

  reply	other threads:[~2015-03-19 20:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19  3:29 [patch 0/7] dt: dtb version: add version info to dtb Frank Rowand
2015-03-19  3:31 ` [patch 1/7] dt: dtb version: consolidate documentation of chosen node bindings Frank Rowand
2015-03-19 13:40   ` Mark Rutland
2015-03-19  3:33 ` [patch 2/7] dt: dtb version: document chosen/dtb-info node binding Frank Rowand
2015-03-19 13:23   ` Rob Herring
2015-03-19 16:42     ` Frank Rowand
2015-03-19 18:41     ` Russell King - ARM Linux
2015-03-19 18:53       ` Mark Rutland
2015-03-19 19:01       ` Frank Rowand
2015-03-19 19:32         ` Russell King - ARM Linux
2015-03-19 20:44           ` Frank Rowand [this message]
2015-03-20 14:42             ` Mark Rutland
2015-03-19 13:49   ` Mark Rutland
2015-03-19 17:02     ` Frank Rowand
2015-03-19 17:23       ` Geert Uytterhoeven
2015-03-19 19:12       ` Mark Rutland
2015-03-19 21:27         ` Frank Rowand
2015-03-20 15:25           ` Mark Rutland
2015-03-19 17:37   ` Frank Rowand
2015-03-19  3:34 ` [patch 3/7] dt: dtb version: arm dts Makefile Frank Rowand
2015-03-19  3:36 ` [patch 4/7] dt: dtb version: kernel Makefile Frank Rowand
2015-03-19  3:38 ` [patch 5/7] dt: dtb version: kbuild scripts Frank Rowand
2015-03-19  3:39 ` [patch 6/7] dt: dtb version: dtsi files Frank Rowand
2015-03-19 18:46   ` Sascha Hauer
2015-03-19  3:41 ` [patch 7/7] dt: dtb version: report dtb info Frank Rowand
2015-03-19  8:12 ` [patch 0/7] dt: dtb version: add version info to dtb Gregory CLEMENT
2015-03-19 17:05   ` Frank Rowand
2015-03-20 13:46 ` Rob Herring
2015-03-20 19:14   ` Uwe Kleine-König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550B3549.1030808@gmail.com \
    --to=frowand.list@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --subject='Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).