In our use case, we added complete paths to the build area's corresponding directory to the embedded include paths and removed the default generated content from our git repo. Consequently only the newly generated content is found, wherever it happens to be placed.
Alan
-----Original Message-----
From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Kevin Peng (Arm Technology China) via TF-M
Sent: Friday, November 22, 2019 2:15 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd
Subject: Re: [TF-M] [EXTERNAL] Re: out of tree build
Hi all,
I'm having issues on supporting the out of tree build.
So I'd like to propose some additional changes.
What does the out of tree build currently support is that:
The user uses the tfm_parse_manifest_list.py with the custom manifests to generate the customized files to a directory out of TF-M.
And the TF-M build system uses the customized files rather than the pre-generated ones in the TF-M for building.
The problem is that some of the source files include the generated headers using the relative path to where the source itself is.
And the directory of the source file is always searched first.
This makes it impossible to use the generated files outside TF-M even the custom output directory is added to searching list.
So I suggest to put the generated files to a dedicated directory in TF-M.
Then for the default build, add the directory and its subdirectories to the search list for headers.
For out of tree build, use the specified directory and its subdirectories instead.
Then there would only one header file with the same name in all the directories for searching headers.
Any concerns, thoughts or suggestions?
Best Regards,
Kevin
-----Original Message-----
From: Kevin Peng (Arm Technology China)
Sent: Friday, November 22, 2019 3:45 PM
To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build
Hi Alan,
I've created a patch for the tfm_parse_manifest_list.py as the first step for the out of tree build support:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2606
The changes for build system is ongoing.
The functionality changes for the tfm_parse_manifest_list.py is the same as your version.
Please have a review and help verify it if possible.
Comments from anyone else are also welcome.
Best Regards,
Kevin
-----Original Message-----
From: Kevin Peng (Arm Technology China)
Sent: Thursday, November 14, 2019 3:31 PM
To: DeMars, Alan <ademars(a)ti.com>
Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build
OK.
It's much clearer for me now. Thanks.
Best Regards,
Kevin
-----Original Message-----
From: DeMars, Alan <ademars(a)ti.com>
Sent: Thursday, November 14, 2019 10:34 AM
To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
Subject: Re: [EXTERNAL] Re: [TF-M] out of tree build
1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files.
2) Yes, I’m building using the unmodified master branch’s cmake build system.
3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree.
Alan
> On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote:
>
> Hi Alan,
>
> I checked your modified tfm_parse_manifest_list.py.
> It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input.
>
> I'm sorry I was not in the workshop. So I have some questions.
> 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M?
> 2. Are you using the TF-M provided CMake build system?
> 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory?
>
> Could you provide some details about your requirements. Thanks.
>
> Best Regards,
> Kevin
>
> -----Original Message-----
> From: Kevin Peng (Arm Technology China)
> Sent: Wednesday, November 13, 2019 10:27 AM
> To: tf-m(a)lists.trustedfirmware.org
> Cc: nd <nd(a)arm.com>
> Subject: RE: out of tree build
>
> Hi Alan,
>
> I'm following on this and will get you updated on any progress.
>
> Best Regards,
> Kevin
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
> Sent: Thursday, November 7, 2019 12:42 PM
> To: Abhishek Pandit <Abhishek.Pandit(a)arm.com>
> Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
> Subject: Re: [TF-M] out of tree build
>
> Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted.
> ---
>
> With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line:
>
> python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir>
>
> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line:
>
> cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../
>
> The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage.
>
> Alan
>
>
> -----Original Message-----
> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M
> Sent: Monday, November 4, 2019 4:36 PM
> To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org
> Subject: [EXTERNAL] Re: [TF-M] out of tree build
>
> Abishek,
>
> Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory.
> A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files.
>
> I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible.
>
> Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise.
>
> Alan
>
> -----Original Message-----
> From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com]
> Sent: Monday, November 4, 2019 3:08 PM
> To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org
> Subject: [EXTERNAL] RE: out of tree build
>
> Hi Alan,
> Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review?
> Thanks,
> Abhishek
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
> Sent: 01 November 2019 16:29
> To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
> Subject: [TF-M] out of tree build
>
> Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them.
>
> Alan
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Thomas,
Tests are placed under the test -> suites -> service name directory.
In your case you are looking at the Secure Storage Service non secure suite.
For SST The logic is located at :
* Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c
* Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c
Hope that helps
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 28 November 2019 14:49
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Regression test issues with IAR port
In my quest to port TF-M to the IAR toolchain I've run into issues with
a few of the tests, and I need some hints where to look.
The cmake build command line:
---
cmake .. -G"Unix Makefiles"
-DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\configs\ConfigRegression.cmake
-DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM
-DCMAKE_BUILD_TYPE=RelWithDebInfo
---
This results in three similar tests that fails:
---
> Executing 'TFM_SST_TEST_1018'
Description: 'Get interface with invalid thread name'
Get should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:936)
TEST FAILED!
> Executing 'TFM_SST_TEST_1019'
Description: 'Get info interface with invalid thread name'
Get info should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1015)
TEST FAILED!
> Executing 'TFM_SST_TEST_1020'
Description: 'Remove interface with invalid thread name'
Remove should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1093)
TEST FAILED!
---
Where do I find the logic that determines if these tests succeed or fails?
Cheers,
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com<http://www.iar.com> <http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
In my quest to port TF-M to the IAR toolchain I've run into issues with
a few of the tests, and I need some hints where to look.
The cmake build command line:
---
cmake .. -G"Unix Makefiles"
-DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\configs\ConfigRegression.cmake
-DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM
-DCMAKE_BUILD_TYPE=RelWithDebInfo
---
This results in three similar tests that fails:
---
> Executing 'TFM_SST_TEST_1018'
Description: 'Get interface with invalid thread name'
Get should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:936)
TEST FAILED!
> Executing 'TFM_SST_TEST_1019'
Description: 'Get info interface with invalid thread name'
Get info should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1015)
TEST FAILED!
> Executing 'TFM_SST_TEST_1020'
Description: 'Remove interface with invalid thread name'
Remove should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1093)
TEST FAILED!
---
Where do I find the logic that determines if these tests succeed or fails?
Cheers,
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Hi Andrej/Kevin,
Pasting the ;Secure Storage' Security Function Requirement below from the PSA Certified Level2 Protection Profile*
It doesn’t specifically mention Protected Storage and Internal Trusted Storage Service as a requirement. As long as the Target of Evaluation can prove that the confidentiality and integrity of assets in Secure Storage can be maintained, the requirement can be met.
PSA defines Protected Storage (PS)** and Internal Trusted Storage (ITS)**. PS is meant to store larger data sets stored on external flash and ITS for device intimate data stored on chip flash storage. If the device doesn’t have an on chip flash storage,
maybe it is still possible to just use PS implementation using external flash to ensure confidentiality and integrity of the secret assets on the platform.
@Marcus Streets<mailto:Marcus.Streets@arm.com> – Could you please share your thought on this
>>>
5.3 F.SECURE_STORAGE
The TOE protects the confidentiality and integrity of assets in a secure storage. The secure storage is bound to
the platform. Only the TOE can retrieve and modify assets from this secure storage.
This security function mitigates T.STORAGE by preventing direct and unprotected access to assets.
>>>
Regards,
Shebu
* https://www.psacertified.org/app/uploads/2019/02/JSADEN002-PSA_Certified_Le…
** https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Im…
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Thursday, November 28, 2019 7:50 AM
To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] PSA Certification without PS?
Hi Kevin,
So, platforms without internal flash memory, required by Internal Trusted Storage, may apply only for PSA L1. Right?
Thank you for your clarification,
Andrej Butok
-----Original Message-----
From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com<mailto:Kevin.Peng@arm.com>>
Sent: Thursday, November 28, 2019 5:14 AM
To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [TF-M] PSA Certification without PS?
A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3.
Best Regards,
Kevin
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M
Sent: Wednesday, November 27, 2019 7:32 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] PSA Certification without PS?
Hello,
Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash.
Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API?
Do you see any issue?
Thanks
Andrej Butok
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3.
Best Regards,
Kevin
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Wednesday, November 27, 2019 7:32 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] PSA Certification without PS?
Hello,
Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash.
Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API?
Do you see any issue?
Thanks
Andrej Butok
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Ken, all,
Right, let's see the binary size of a prototype.
Regarding TBB instruction, It's applied at the stage of binary generation, after source parsing and references resolution so it is irrelevant to the problem of dead references, I have mentioned.
The best,
Anton
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M
Sent: 22 November 2019 10:23
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] The svcall switch-case vs function table
Hi Anton,
Thanks for the reminder.
About code size, two points:
- We saved code size for switch/case usage: switch(num) {case1:case2:} -> func_tbl[num].func();
- The compiler uses 'TBB' instruction, which is a function table already.
So I think it should be okay; we can verify the code size after the prototype is available.
BR
/Ken
-----Original Message-----
From: Anton Komlev <Anton.Komlev(a)arm.com>
Sent: Thursday, November 21, 2019 8:09 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com>
Subject: RE: The svcall switch-case vs function table
Hi Ken, All,
Just a reminder of a side-effect of array-based function table. It creates unconditional reference to a function and blocks that function from removal during code size optimization. TF-M is quite sensitive to binary image size and we should be very careful to avoid its increase.
This is a general comment on functions table, irrelevant to the patch, where I have no knowledge yet to comment.
The best,
Anton
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M
Sent: 14 November 2019 09:33
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] The svcall switch-case vs function table
Hi,
I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations.
Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros?
This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros.
Welcome to comment or propose patches for this.
Thanks.
/Ken
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hello,
Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash.
Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API?
Do you see any issue?
Thanks
Andrej Butok
Hello, I do also support the move to loose the requirement of 80 columns. The real need is outdated and supported as a legacy style, making more trouble than help.
The best,
Anton
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Laurence Lundblade via TF-M
Sent: 26 November 2019 21:12
To: Tamas Ban <Tamas.Ban(a)arm.com>
Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Coding guideline
For line length I’m following these rules for t_cose <https://github.com/laurencelundblade/t_cose>
- All comments blocks are 80 columns or less
- 2% of code lines can be over 80 columns (1% is too few)
- No lines over 120 columns
I am much happier and think the code is much better by allowing 2% of code lines over 80 columns. I don’t have to make variable names short and obscure, break up if statements in unnatural places, break up for(;;) statements unnaturally and such.
LL
> On Nov 18, 2019, at 8:31 AM, Tamas Ban <Tamas.Ban(a)arm.com> wrote:
>
> Hi,
>
> I would like to open a conversation about TF-M coding guideline <https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals:
> Change the rule of the 80 character column width:
> Max 80 characters length.
> Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character:
> Degrades code understandability: short, obscured variable names;
> awkward line breaks Maximum 1% of the lines can exceed 80 charter length.
> Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API:
> o Order function parameters so that input params are before output params.
> o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… <https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu…>
>
> I’m interested in your opinions! Other rules also can be revisited!
>
> Tamas
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
Build environment provisioning (and dependency management) is a larger topic and sub-modules can only solve a small part of it. There is definitely room for improvement in this area, but as far as I can see sub-modules are a sub optimal answer.
Some of the issues which came to my mind:
1. The user experience of sub-modules is sometimes quirky. For example it is a headache if you have to switch between branches where one of the branches does not have a specific sub-module.
2. With sub-modules you can not have complex dependencies. I.e.: when one platform needs a dependency and another not, or you need two version of a dependency, or a different version for two platforms.
3. It is easy to see on what the repo having the sub-module depends, but the other direction is not. It is hard to see what is using a module.
4. The validness of tests are limited if you use source code. Longer term it would be nice to allow using tested binaries of tf-m dependencies and sub-modules can not handle this need.
5. Flexibility. If we use sub-modules, then the version control and the dependency handling "layers" get bounded. For tf-m developers this might not be an issue but for integrators it can be.
Can you please explain the problem you see a bit more? Zephyr is using cmake and you could use the External_project or the FetchContent module to get all needed dependencies. Also nothing really stops you to use sub-modules in the Zephyr repo to get tf-m and all it's dependencies.
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M
Sent: 26 November 2019 19:23
To: Kumar Gala <kumar.gala(a)linaro.org>
Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Using git submodules for dependencies?
Hi,
I'm reviving an old thread (sorry, probably bad form), but we're running into this issue again now with Zephyr (and probably with FreeRTOS later) where we need to produce a TF-M 'module' got Zephyr that we can include in the zephyr github repo. With the current approach for TF-M, we will have to produce 5 forks of the 5 projects/dependencies, which seems superfluous versus a single 'master' TF-M repo with the four dependencies as sub-modules, and I can't see why technically this would be more of a challenge for end-users (you can even init the submodules at the same time you clone the parent TF-M repo so it's actually LESS work), and means a single repo where all of the dependency versions can change over time in sync with the various releases.
I may be missing or misunderstanding an obvious technical drawback made earlier, but I haven't understand why submodules are less desirable than
1+4 independent repos both for TF-M and any projects on the RTOS side
depending on it?
Kevin
On Wed, 10 Jul 2019 at 18:09, Kumar Gala via TF-M < tf-m(a)lists.trustedfirmware.org> wrote:
> How would a git repo with some submodules preclude any of the things
> you mentioned? I guess my initial thought is that there would be an “uber”
> repo in which TFM, CMSIS and mbedcrypto would all be sub-modules.
>
> There’s also the option of using cmake ExternalProject (
> https://cmake.org/cmake/help/latest/module/ExternalProject.html?highli
> ght=external
> )
>
> Or west
>
> https://pypi.org/project/west/
>
> - k
>
> > On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M <
> tf-m(a)lists.trustedfirmware.org> wrote:
> >
> > Hi,
> >
> > Initial idea was to keep the external dependencies clearly visible
> > (from
> code auditability point of view). With submodule we can't checkout the
> dependencies out of tree. Since the dependencies need to be checked
> out only once it was considered acceptable nuisance, until you do a
> pull and version of the dependencies have changed.
> > 'repo' was considered as well, but repo tool doesn't work on
> windows(last I checked).
> >
> > Thanks,
> > Ashu
> >
> > -----Original Message-----
> > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of
> > Kumar
> Gala via TF-M
> > Sent: 10 July 2019 09:50
> > To: Andrej Butok <andrey.butok(a)nxp.com>
> > Cc: tf-m(a)lists.trustedfirmware.org
> > Subject: Re: [TF-M] Using git submodules for dependencies?
> >
> > There can always be a fork of the sources kept in TF-M repos to
> > handle
> the case of needing local modifications for some reason.
> >
> > - k
> >
> >> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <
> tf-m(a)lists.trustedfirmware.org> wrote:
> >>
> >> Hi Kevin,
> >>
> >> Only if 100% of the external project source code is used without
> change.
> >> Even if it is valid now, nobody will give you this guarantee in future.
> >>
> >> Regards,
> >> Andrej
> >>
> >> -----Original Message-----
> >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of
> >> Kevin
> Townsend via TF-M
> >> Sent: Wednesday, July 10, 2019 10:41 AM
> >> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
> >> Subject: [TF-M] Using git submodules for dependencies?
> >>
> >> Hi,
> >>
> >> I'm currently working on integrating TF-M into Zephyr and getting
> >> TF-M
> working with QEMU. Part of that work is simplifying the setup and
> build process to generate a TF-M secure library.
> >>
> >> Was the idea of git submodules for dependencies considered and rejected?
> >> Using sub-modules would reduce the number of setup steps required,
> >> and
> pair external dependency versions with specific TF-M commits/releases.
> >>
> >> There may be a valid reason this approach was rejected, but it
> >> seems
> like a sensible option on the surface?
> >>
> >> Best regards,
> >> Kevin Townsend
> >> --
> >> TF-M mailing list
> >> TF-M(a)lists.trustedfirmware.org
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca
> ndrey.butok%40nxp.com%7C04856a3b68604d01153208d705124e6a%7C686ea1d3bc2
> b4c6fa92cd99c5c301635%7C0%7C0%7C636983448498201722&sdata=IjOFM44xG
> bA2Zgrj%2F2VSmHEYLuXvMzqS7HH6h7gekF4%3D&reserved=0
> >> --
> >> TF-M mailing list
> >> TF-M(a)lists.trustedfirmware.org
> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
> >
> > --
> > TF-M mailing list
> > TF-M(a)lists.trustedfirmware.org
> > https://lists.trustedfirmware.org/mailman/listinfo/tf-m
> > --
> > TF-M mailing list
> > TF-M(a)lists.trustedfirmware.org
> > https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
I would like to open a conversation about TF-M coding guideline<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals:
* Change the rule of the 80 character column width:
* Max 80 characters length.
* Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character:
* Degrades code understandability: short, obscured variable names; awkward line breaks
* Maximum 1% of the lines can exceed 80 charter length.
* Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API:
o Order function parameters so that input params are before output params.
o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu…
I'm interested in your opinions! Other rules also can be revisited!
Tamas
