[RFC v7 03/21] um: move arch/um/os-Linux dir to tools/um/uml
Johannes Berg
johannes at sipsolutions.net
Fri Oct 9 11:59:33 EDT 2020
On Thu, 2020-10-08 at 23:53 +0300, Octavian Purdila wrote:
> Leaving the library/standalone build itself aside for a while, do you
> agree that the various tools we are building with library mode should
> be placed in tools? Things like lklfuse - mounting Linux filesystems
> with fuse, or lklhijack.so - a preload library that intercept
> network/file system calls and routes them through the library mode.
Yeah, I guess that makes sense. I realize the line gets blurry ...
OTOH, should these even live in the kernel tree? Almost seems like if
the base lkl library is there, the other stuff might not really need to
be, it's supposed to use the (stable) syscall API?
Dunno. Not sure "doesn't need to be" really is an argument for
"shouldn't be" anyway.
> > You're looking at it the other way around I think - it seems that you're
> > thinking the kernel binary is the vmlinux.a, and that's what the
> > kernel's build system worries about; then the "vmlinux.so" (library
> > mode) or "linux" (standalone mode - perhaps that's a good name?) is the
> > eventual 'tool' that we build, using the previously built vmlinux.a.
> >
>
> Correct, this is my perspective.
>
> > But that really isn't how standalone mode works, and IMHO it also
> > doesn't match what tools are today.
> >
>
> What if we could use standalone mode for other purposes that would
> require creating a new binary in addition to the current linux binary?
Anything specific you have in mind?
But I still think that "UML standalone 'linux' binary" is something that
seems like the kernel build system should be able do? If only to avoid
regressions from what we have now ...
johannes
More information about the linux-um
mailing list