linux-kernel - Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

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]

Date:	Sun, 28 Jul 2013 15:39:56 +0200
From:	Tomasz Figa <tomasz.figa@...il.com>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	Arend van Spriel <arend@...adcom.com>,
	Olof Johansson <olof@...om.net>,
	Mark Brown <broonie@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"ksummit-2013-discuss@...ts.linuxfoundation.org" 
	<ksummit-2013-discuss@...ts.linuxfoundation.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Ian Campbell <ian.campbell@...rix.com>,
	Pawel Moll <Pawel.Moll@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Domenico Andreoli <cavokz@...il.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Dave P Martin <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

On Sunday 28 of July 2013 15:19:03 Richard Cochran wrote:
> On Sun, Jul 28, 2013 at 11:12:53AM +0200, Tomasz Figa wrote:
> > I'm not really sure what effect on users this has. Maybe you should
> > define "users".
> 
> ...
> 
> > Care to explain this reasoning?
> 
> Use Case
> ~~~~~~~~
> 
> User acquires a machine running ARM Linux version 3.x, with u-boot
> and dtb in a read only flash partition. The board boots and works just
> fine. However, for his application, the user requires a new kernel
> feature that appeared in version 3.y where y > x. He compiles the new
> kernel, and it also works.

Generally the user does not care where the dtb is stored. He just want to 
upgrade the kernel without thinking about internals.

There are many possible options:

a) The BSP packaging script he received from board vendor, or even kernel 
build system, builds dtb from kernel sources and appends it to built 
zImage. He just flashes the zImage and everything is working correctly.

  This is pretty common case today, as many boards still use legacy 
  bootloaders without native support for DT. See the analogy to board 
  files, being compiled as a part of kernel sources.

b) The user always compiles the kernel and dtb and flashes both at the 
same time.

  This does not differ at all to flashing the kernel alone, except two 
  files, not one, need to be flashed.

By the way, in use case you are describing, changes that dtb wouldn't have 
to be updated are very low, unless the one present in read only memory of 
the board is complete, i.e. fully describes all the available hardware, 
which is unlikely for a dtb built at time of 3.x availability, whenever 
the feature showed up in 3.y (y > x). The user will most likely have to 
update the dtb anyway.

Please note, though, I'm _not_ trying to convince you that this kind of 
solutions is good, as I'm not convinced either. That's why we are 
discussing this.

Best regards,
Tomasz

--
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/