On Tue, Mar 16, 2021 at 11:32 PM Johannes Berg
[off-list ref] wrote:

On Tue, 2021-03-16 at 10:19 +0900, Hajime Tazaki wrote:

quoted

quoted

quoted

--- 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.

I agree. I think these can stay in defconfigs but here is where a
library introduces complications which I don't know how is best to
handle. Should we have the defconfig in arch/um or should we have it
in tools/testing/selftests/um? Or perhaps both places, one being a
generic config that would be used by most applications and one
customized?