On Tue, Mar 16, 2021 at 11:32 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > 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. > 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?
