Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752852AbdHOX7y (ORCPT ); Tue, 15 Aug 2017 19:59:54 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:33812 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752322AbdHOX7v (ORCPT ); Tue, 15 Aug 2017 19:59:51 -0400 Subject: Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files To: Rob Herring , Tom Rini References: <1502831736-28282-1-git-send-email-trini@konsulko.com> <59938A6B.4050906@gmail.com> Cc: "devicetree@vger.kernel.org" , Tero Kristo , Nishanth Menon , Tomi Valkeinen , Sekhar Nori , Rob Herring , Masahiro Yamada , Michal Marek , Pantelis Antoniou , Linux Kernel Mailing List , linux-kbuild@vger.kernel.org From: Frank Rowand Message-ID: <59938AF2.1040702@gmail.com> Date: Tue, 15 Aug 2017 16:59:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <59938A6B.4050906@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6227 Lines: 140 On 08/15/17 16:57, Frank Rowand wrote: > On 08/15/17 15:36, 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, >> >> Plus some amount for the unflattened tree in memory, too. >> >>> 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. >> >> Agree completely. I don't even like that building dtbs depends on the ARCH. >> >> 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). > > Yes. I would prefer to treat the __symbols__ node as an internal > representation of information used by the device tree subsystem. > It is not hardware description. > > >> The complication is >> always kexec which I haven't thought about too much here. > > That should not be an issue, because the device tree is exposed to kexec > via /sys/firmware/fdt instead of /sys/firmware/devicetree/base (which > is what /proc/device-tree links to), according to > Documentation/ABI/testing/sysfs-firmware-ofw. So the __symbols__ > node will be exposed to kexec. > > >> Also, perhaps we need finer grain control of __symbols__ generation. >> 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. > > Agreed. We could also restrict labels in connector nodes to be visible. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I meant to say restrict visibility of labels, so that only labels in connector nodes would be visible. > > >>> Second, I think this is out of step with how a lot of overlay usage will >>> occur. My thinking is that with maximally useful overlays being >>> available in mainline, lots of use-cases that we have today that result >>> in a number of DTS files being included can become just overlays. This >>> is true in terms of not only evaluation kits but also when these systems >>> are turned into custom hardware. This is even more true for SoM based >>> systems where a physical widget would be a SoM + carrier overlay + >>> custom parts overlay. These cases are going to be resolved with >>> overlays being applied outside of the kernel. >>> >>> Signed-off-by: Tom Rini >>> --- >>> drivers/of/unittest-data/Makefile | 5 ----- >>> scripts/Makefile.lib | 3 +++ >>> 2 files changed, 3 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile >>> index 6e00a9c69e58..70731cfe8900 100644 >>> --- a/drivers/of/unittest-data/Makefile >>> +++ b/drivers/of/unittest-data/Makefile >>> @@ -11,8 +11,3 @@ targets += overlay_base.dtb overlay_base.dtb.S >>> .PRECIOUS: \ >>> $(obj)/%.dtb.S \ >>> $(obj)/%.dtb >>> - >>> -# enable creation of __symbols__ node >>> -DTC_FLAGS_overlay := -@ >>> -DTC_FLAGS_overlay_bad_phandle := -@ >>> -DTC_FLAGS_overlay_base := -@ >>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib >>> index 58c05e5d9870..a1f4a6b29d75 100644 >>> --- a/scripts/Makefile.lib >>> +++ b/scripts/Makefile.lib >>> @@ -293,6 +293,9 @@ DTC_FLAGS += -Wnode_name_chars_strict \ >>> -Wproperty_name_chars_strict >>> endif >>> >>> +# enable creation of __symbols__ node >>> +DTC_FLAGS += -@ >>> + >>> DTC_FLAGS += $(DTC_FLAGS_$(basetarget)) >>> >>> # Generate an assembly file to wrap the output of the device tree compiler >>> -- >>> 1.9.1 >>> >> . >> > >