Page MenuHomePhabricator

Taking configuration values from the environment in TF-A makefiles
Open, Needs TriagePublic

Description

This is a suggestion to consider changing the strategy on how configuration variables of the build system can be set.

Currently the TF-A build system implement a strategy where the value of configuration variables can only be set with command line parameters.
On one end this has the benefit of safety as it avoids variable name collisions in the global namespace of environment variables, but on the other end this makes life of integrators harder as it is not possible to "inject" configuration settings from "global scope".

This issue came up, in a scenario, where TF-A build is controlled by an integration system (OP-TEE makefiles), and the integration system is run by a higher layer test system. The integration system owns the TF-A configuration options which configure TF-A features. The test system owns TF-A settings related to the test environment (e.g. OPENSSL binary location). But the TF-A build system does not allow multiple owners as the parameters can only be set on the command line, which cannot be set by multiple parties. A workaround could be to enhance the integration system to allow amending TF-A parameters from higher layers, but this does not scale, as each further option owner will need interface changes.

Technical details on how TF-A build system works in this aspect.
When make starts, it duplicates all environment variables as respective make variables. The value of these variables can be overridden in the makefile, or if the makefile is written so, the values can be kept. make implements a complex priority scheme how variables get their values. (See the make documentation for details.)
In TF-A defaults.mk (and possibly other makefiles) use := operator to set default values for configuration variables. This operator will override any value mirrored from environment variables. The ?= operator in turn would keep the value already set.

Suggested actions:

  • investigate risk of environment variable name collision and cost of mitigation and make a decision if a change is worth or not
  • investigate which makefiles need changing
  • replace := operators with ?= where needed
  • this might become a significant build system interface change and a rollout plan may be needed
  • roll out the changes
  • have 🍺 :)

Event Timeline

I agree with the idea and its a good capability to have. I don't thing there will be many TF-A build flags which has chance of name collision with environment variables. we can add TF-A prefix to them.

Can we add suika game to the TF-A suffix and what is the result?

I want to express my utmost gratitude to the author for their meticulous research and extensive exploration of various facets of the only up subject, making this article a valuable resource for readers.

Interesting perspective on TF A build system configurations. The suggestion to explore the risk of environment variable collisions and potential interface changes seems well reasoned. Wishing a smooth rollout of the proposed modifications.
Best Mortgage Broker in West Sacramento CA

Thanks for reporting this. طلا فیلم

Many games require players to plan and strategize Geometry Dash carefully to achieve their goals. This process develops critical thinking skills, which can also be applied in real-life situations like problem-solving and decision-making.