On Tue, 2021-03-16 at 10:19 +0900, Hajime Tazaki wrote: > > > > --- a/arch/um/Kconfig > > > +++ b/arch/um/Kconfig > > > @@ -29,6 +29,10 @@ config UMMODE_LIB > > > select UACCESS_MEMCPY > > > select ARCH_THREAD_STACK_ALLOCATOR > > > select ARCH_HAS_SYSCALL_WRAPPER > > > + select VFAT_FS > > > + select NLS_CODEPAGE_437 > > > + select NLS_ISO8859_1 > > > + select BTRFS_FS > > > > That doesn't really seem to make sense - the sample might need it, but > > generally LKL doesn't/shouldn't? > > I'm trying to understand your comment; > Do you mean that enabling those options in Kconfig doesn't make sense ? I mean *always* enabling them doesn't make sense. Why shouldn't somebody be allowed to build UMMODE_LIB *without* btrfs? If they have no need for btrfs, why should it select it? I can understand that your sample code wants btrfs just to show what it can do, but IMHO it doesn't make sense to *always* enable it. > and if you mean the sample as sample code, is the added test case > (e.g., tools/testing/selftests/um/disk.c, which is included in the > same patch) for this purpose ? yes, that's what I mean by "sample code" joahnnes
