From 6a7b3ce7edcdceb664c56f19280d14b8f442cba4 Mon Sep 17 00:00:00 2001 From: Louis Mayencourt Date: Mon, 9 Mar 2020 16:43:25 +0000 Subject: [PATCH] fconf: Add namespace guidance inside documentation Change-Id: I50707d1836c7f5e4ef162c00256624a1f278baef Signed-off-by: Louis Mayencourt --- docs/components/fconf.rst | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/docs/components/fconf.rst b/docs/components/fconf.rst index cec3cebe4..0e0f0756f 100644 --- a/docs/components/fconf.rst +++ b/docs/components/fconf.rst @@ -83,3 +83,30 @@ This function will call all the ``populate()`` callbacks which have been registered with ``FCONF_REGISTER_POPULATOR()``. .. uml:: ../resources/diagrams/plantuml/fconf_bl2_populate.puml + +Namespace guidance +~~~~~~~~~~~~~~~~~~ + +As mentioned above, properties are logically grouped around namespaces and +sub-namespaces. The following concepts should be considered when adding new +properties/namespaces. +The framework differentiates two types of properties: + - Properties used inside common code. + - Properties used inside platform specific code. + +The first category applies to properties being part of the firmware and shared +across multiple platforms. They should be globally accessible and defined +inside the ``lib/fconf`` directory. The namespace must be chosen to reflect the +feature/data abstracted. +Example: + - |TBBR| related properties: tbbr.cot.bl2_id + - Dynamic configuration information: dyn_cfg.dtb_info.hw_config_id + +The second category should represent the majority of the properties defined +within the framework: Platform specific properties. They must be accessed only +within the platform API and are defined only inside the platform scope. The +namespace must contain the platform name under which the properties defined +belong. +Example: + - Arm io framework: arm.io_policies.bl31_id +