[PATCH v2 12/29] fs: Disable sandbox filesystem in SPL

[Sean Anderson]

On 10/14/23 17:14, Heinrich Schuchardt wrote:
> 
> 
> Am 14. Oktober 2023 22:47:48 MESZ schrieb Sean Anderson <seanga2 at gmail.com>:
>  >Don't bother compiling the sandbox filesystem in SPL for now, as it is not
>  >needed.
>  >
>  >Signed-off-by: Sean Anderson <seanga2 at 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