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