On 10/14/23 17:14, Heinrich Schuchardt wrote:
Am 14. Oktober 2023 22:47:48 MESZ schrieb Sean Anderson <sean...@gmail.com>:
>Don't bother compiling the sandbox filesystem in SPL for now, as it is not
>needed.
>
>Signed-off-by: Sean Anderson <sean...@gmail.com>
>---
>
>Changes in v2:
>- Disable sandbox filesystem in SPL instead of compiling it in
>
> fs/fs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/fs/fs.c b/fs/fs.c
>index cfc781bbb8d..4cb4310c9cc 100644
>--- a/fs/fs.c
>+++ b/fs/fs.c
>@@ -237,7 +237,7 @@ static struct fstype_info fstypes[] = {
> .mkdir = fs_mkdir_unsupported,
> },
> #endif
>-#ifdef CONFIG_SANDBOX
>+#if IS_ENABLED(CONFIG_SANDBOX) && !IS_ENABLED(CONFIG_SPL_BUILD)
Why do would you disable the sandbox file system in SPL for
CONFIG_SANDBOX_SPL=y?
It was never enabled in the first place, since we never had fs.c compiled in SPL
before. This just fixes linking.
I cannot see that this is necessary to enable the unit tests you are striving
for. Instead we should extend the SPL unit tests to sandbox_spl_defconfig in
the long run.
The purpose of the sandbox filesystem is to test routines which use the
filesystem
API in U-Boot. However, there are very few which do so in SPL. SPL_FS_LOADER is
the
only one I know of off the top of my head. However, FS_LOADER is tested in
U-Boot
proper. I don't think there is a pressing need to enable the sandbox filesystem
in SPL.
--Sean
