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.loz...@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