[RFC v8 19/20] um: lkl: add block device support of UML

[Octavian Purdila]

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