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-walte...
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