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

[Walter Lozano]

Hi Rasmus,

On 7/7/20 11:53, Rasmus Villemoes wrote:
> 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.

I agree with you regarding the fact that the chances of a false positive 
are low, and also causes no big issue, just some node we don't remove. 
However as much of the support in dtoc is already there for other 
features I I think is cleaner in that way. Not sure what other people think.

>> 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.
>
Yes, I also agree with you, that this could be error-prone, that is my 
main concern, and that is the reason for sending this RFC, to explore 
this (and possible other) ideas or approaches to reduce the footprint.

To elaborate a bit more, I think the scanning the Makefiles could be 
error-prone, and could lead to some file driver not being taken into 
account, which could lead to runtime issues. On the other hand, I don't 
see much of a problem to use some macros which will be implemented in 
code generated by dtoc, as this idea is already used for OF_PLATDATA.

If you see some specific issue please let me know.

Thanks for sharing you thoughts, it is very useful. I will keep thinking 
about your suggestions and different alternatives.

Regards,

Walter

> Rasmus
>