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

[Hajime Tazaki]

On Wed, 17 Mar 2021 23:28:10 +0900,
Johannes Berg wrote:
> 
> On Wed, 2021-03-17 at 16:19 +0200, Octavian Purdila wrote:
> > > 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.
> 
> Btw, what I said there also didn't distinguish between "always enable
> it" and "always force it enabled".
> 
> Right now this patch did the latter, but the former might sort of make
> sense, but would take the form of a defconfig rather than a Kconfig code
> change.

Thanks, I understand the situation.
I agree that using defconfig should be good in this case.  Will fix this.


> > 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?
> 
> Yeah, that's a question - and in that sense LKL will never be a general-
> purpose "library" since then you'd have to basically build it with
> "allyesconfig" instead of other things.
> 
> Maybe just put a note there with the tools, and maybe a defconfig, and
> then have some kind of detection at example/tool build or even runtime
> that the necessary options are selected?

preparing multiple defconfigs (e.g., tiny, normal, allyes) would be
one option for build-time selection.

Other possibilities (rather radical) could be to prepare multiple
sub-libraries (liblinux-core.so liblinux-fs-ext4.so, liblinux-net.so,
etc) so that users can pick only necessary codes when it's build (or
open during runtime).  This needs to handle dependencies as kernel
modules do, thus it's more complicated once we have this ?

-- Hajime