Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files

[Frank Rowand]

On 08/15/17 15:36, Rob Herring wrote:
> On Tue, Aug 15, 2017 at 4:15 PM, Tom Rini <trini@xxxxxxxxxxxx> 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 <robh+dt@xxxxxxxxxx>
>> Cc: Frank Rowand <frowand.list@xxxxxxxxx>
>> Cc: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
>> Cc: Michal Marek <mmarek@xxxxxxxx>
>> Cc: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx>
>> Cc: devicetree@xxxxxxxxxxxxxxx
>> Cc: linux-kernel@xxxxxxxxxxxxxxx
>> CC: linux-kbuild@xxxxxxxxxxxxxxx
>> Signed-off-by: Tom Rini <trini@xxxxxxxxxxxx>
>> ---
>> 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.


>> 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 <trini@xxxxxxxxxxxx>
>> ---
>>  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
>>
> .
>