[RFC 1/4] dtoc: add POC for dtb shrink

[Rasmus Villemoes]

On 07/07/2020 16.32, Walter Lozano wrote:
> Hi Rasmus,
> 
> On 7/7/20 11:15, Rasmus Villemoes wrote:
>> On 19/06/2020 23.11, Walter Lozano wrote:
>>
>>> Some additional reduction could be possible by only keeping the nodes
>>> for
>>> whose compatible string is supported by any enabled driver. However,
>>> this requires to add extra logic to parse config files and map
>>> configuration to compatible strings.
>> If this can be done after building the U-Boot (or SPL) ELF, can't it
>> just be done by doing 'grep -a' on that? Or, probably a little more
>> efficient, running "strings | grep -E '^[a-zA-Z0-9,._-]*' | sort -u",
>> slurping in the output of that in a python set() and just looking there.
>>
> Thanks for your review and suggestion. Your approach is interesting,
> however, I wonder, won't we get a lot of strings which are not
> compatible strings? How could be filter this list to only include those
> strings that are compatible strings?

Does it matter? You have a dt node containing 'compatible =
"acme,frobnozzle"', so you want to know if any enabled driver has
"acme,frobnozzle". Sure, the brute-force grep'ing will produce lots and
lots of irrelevant strings, but the chance of a false positive
(acme,frobnozzle appearing, but not from some driver's compatible
strings) should be quite low, and false negatives can't (and must not,
of course) happen AFAICS.

> Also the idea if parsing config and Makefiles would be useful to only
> process file drivers which are going to be used, and prepare for
> instance the compatible string list as described in "[RFC 3/4] dtoc: add
> support for generate stuct udevice_id", which can be found in
> 
> https://patchwork.ozlabs.org/project/uboot/patch/20200619211140.5081-4-walter.lozano@collabora.com/
> 
> 
> Do you think we can handle this in some other more efficient way?

I haven't read these patches very closely, just stumbled on the above. I
do think that the job of parsing Kconfig files is best left to Kconfig,
the job of parsing Makefiles is best left to make, and the job of
processing all the #ifdefery/CONFIG_IS_ENABLED stuff is best left to the
compiler (preprocessor). Trying to predict which code will or will not
be included in a given image in any way other than by building that
image sounds quite error-prone. But I may very well not have understood
what you're proposing.

Rasmus