Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752859AbdHOWt2 (ORCPT ); Tue, 15 Aug 2017 18:49:28 -0400 Received: from mail-yw0-f182.google.com ([209.85.161.182]:35919 "EHLO mail-yw0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752453AbdHOWt0 (ORCPT ); Tue, 15 Aug 2017 18:49:26 -0400 Date: Tue, 15 Aug 2017 18:49:24 -0400 From: Tom Rini To: Rob Herring Cc: "devicetree@vger.kernel.org" , Tero Kristo , Nishanth Menon , Tomi Valkeinen , Sekhar Nori , Rob Herring , Frank Rowand , Masahiro Yamada , Michal Marek , Pantelis Antoniou , Linux Kernel Mailing List , linux-kbuild@vger.kernel.org Subject: Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Message-ID: <20170815224924.GG20467@bill-the-cat> References: <1502831736-28282-1-git-send-email-trini@konsulko.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5imY3Jz7H3s+WDia" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5367 Lines: 117 --5imY3Jz7H3s+WDia Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 15, 2017 at 05:36:11PM -0500, Rob Herring wrote: > On Tue, Aug 15, 2017 at 4:15 PM, Tom Rini wrote: > > With support for stacked overlays being part of libfdt it is now > > possible and likely that overlays which require __symbols__ will be > > applied to the dtb files generated by the kernel. This is done by > > passing -@ to dtc. This does increase the filesize (and resident memory > > usage) based on the number of __symbol__ entries added to match the > > contents of the dts. > > > > Cc: Rob Herring > > Cc: Frank Rowand > > Cc: Masahiro Yamada > > Cc: Michal Marek > > Cc: Pantelis Antoniou > > Cc: devicetree@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > CC: linux-kbuild@vger.kernel.org > > Signed-off-by: Tom Rini > > --- > > In order for a dtb file to be useful with all types of overlays, it > > needs to be generated with the -@ flag passed to dtc so that __symbols__ > > are generated. This however is not free, and increases the resulting > > dtb file by up to approximately 50% today. In the current worst case > > this is moving from 88KiB to 133KiB. In talking with Frank about this, >=20 > Plus some amount for the unflattened tree in memory, too. >=20 > > he outlined 3 possible ways (with the 4th option of something else > > entirely). > > > > 1. Make passing -@ to dtc be dependent upon some CONFIG symbol. > > 2. In the kernel, if the kernel does not have overlay support, discard > > the __symbols__ information that we've been passed. > > 3. Have the bootloader pass in, or not, __symbols__ information. > > > > This patch is an attempt to implement something between the 3rd option > > and a different, 4th option. Frank was thinking that we might introduce > > a new symbol to control generation of __symbol__ information for option > > 1. I think this gets the usage backwards and will lead to confusion > > among users and developers. > > > > My proposal is that we do not want __symbols__ existence to be dependent > > on some part of the kernel configuration for a number of reasons. > > First, this is out of step with the rest of how dtbs are created today > > and more importantly, thought about. Today, all dtb content is > > independent of CONFIG options. If you build a dtb from a given kernel > > tree, everyone will agree on the result. This is part of the "contract" > > on passing old kernels and new dtb files even. >=20 > Agree completely. I don't even like that building dtbs depends on the ARC= H. >=20 > However, option 2 may still be useful. There's no point exposing what > can't be used. Furthermore, exposing __symbols__ in /proc/device-tree > at all may be a bad idea. We should consider if it should always be > hidden. That would also allow storing the __symbols__ data however we > want internally (i.e. with less memory usage). The complication is > always kexec which I haven't thought about too much here. A further patch to the kernel at run-time, OK. If you give me some crumbs I'll see if I can figure out the next steps. > Also, perhaps we need finer grain control of __symbols__ generation. Here I have to disagree. > We really don't want userspace to be able to modify anything in the DT > at any point in time. That's a big can of worms and we don't want to > start there. The problem is labels are widely used just for > convenience and weren't part of the ABI. With overlays that changes, > so we either need to restrict labels usage or define another way. It > could be as simple as defining some prefix for label names for labels > to export. I think there needs to be a difference noted between "here is what policy the kernel is going to enforce about run time changes" and "here is what the user is going to assemble a system to look like". Again, stemming from the part where the Linux kernel is where dts files reside and are generated from normally. If we have it in __symbols__, someone can make use of it in hardware design (again, think of the SoM + carrier + custom) bit, I've seen so many real life products now that would be simplified in this manner). Thanks! --=20 Tom --5imY3Jz7H3s+WDia Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJZk3pzAAoJEIf59jXTHXZSdmsP/i68XnMHLRs6WqQzvXu0kwXk TtOSP7AHierlnbqed23Ws/9rHVa2th85zjZH07fRdibjyQGzsw0FqRmIExOCfd8H e0crTq4skji5+rcp3e1I6mwvDCD2eeDtUNh3OLEnfphlpUg+RVDvSUj/Ng7+zeOg UHw47PSRng+2PJZyqr5JpTUABJU2/YLriSnprVyoXnSpDnrrYLd4I3az4wCr05FF 8tH+dexpxjh2VeMykP57fWmGMOlXhpDLDuG9QItuF0cLKehZq6QYJzG9E4jN/uNw xzq92vyA7LVLXepZHnWGgfXTG0FbJU0ih0rS1G83yH9ZTck9AUILgIt8OWkHWKHc BJPA+p2l11yiM0JbAMZ6NcGKKVlqHlelEuRuQQt8oUuNhnS5DUf7FvtNOTgVZ8Ky y2jGX9z7M3YXmHS0DqUBxS4Jcy1iDs8XJWsxVS+3tWQP5h67kEqzNOCfsNLkbiS2 7wuzNDQ9qEds+IA+KyS6epfAhD3UidwcPeK+3Yf928BhgxQQZ8p26EXIp/a0gyQW l6g4vOF/Er/XNaKv6rDtooNM9JrFEtw8d6i8y6LnmOct8bQhQqQtE0WKE0hSm+FG aKSxZtgofjQ5qlSl9KfBWpe/6ovq8M/zTSs6c2aii6XSJ3zq+hmZwtynph2wLGw6 0pgRvnBc/VE5RjMMw8ez =pqTS -----END PGP SIGNATURE----- --5imY3Jz7H3s+WDia--