[RFC v7 03/21] um: move arch/um/os-Linux dir to tools/um/uml

[Johannes Berg]

On Thu, 2020-10-08 at 20:48 +0300, Octavian Purdila wrote:

> > On Tue, 2020-10-06 at 18:44 +0900, Hajime Tazaki wrote:
> > > This patch moves underlying OS dependent part under arch/um to tools/um
> > > directory so that arch/um code does not need to build host build
> > > facilities (e.g., libc).
> > 
> > Hmm. On the one hand, that build separation seems sensible, but on the
> > other hand this stuff *does* fundamentally belong to arch/um/, and it's
> > not a "tool" like basically everything else there that is a pure
> > userspace application to run *inside* the kernel, not *part of* it.
> > 
> > For that reason, I don't really like this much.
> > 
> 
> I see the os_*() calls as dependencies that the kernel uses. Sort of
> like calls into the hypervisor or firmware.

Right.

> The current UML build is already partially split. USER_OBJS build with
> a different rule set than the rest of the kernel objects.

Yes, that's true.

> IMHO this
> change just makes this more clear and streamlined, especially with
> regard to linking.

Well, maybe? But I actually tend to see this less as a question of
(technical) convenience but semantics, and the tools are just not
*meant* to be things that build a kernel, they're things to be used
inside that kernel.

I dunno. Maybe the technical convenience should win, but OTOH the
"contortions" that UML build goes through with USER_OBJS don't really
seem bad enough to merit breaking the notion of what tools are?

> We are using the same build system as the rest of the stuff in tools.
> Since it is building programs and libraries and not part of the kernel
> binary build, it is using a slightly different infrastructure, which
> is detailed in tools/build/Documentation/Build.txt

OK, thanks for the pointer, I hadn't seen that before.

> The reason for picking tools was that it already has the
> infrastructure to build programs and shared libraries and the fact
> that it is the only place in the kernel source tree where code is not
> built directly into the kernel binary.

Yeah, but all of UML/LKL _is_ eventually built into the kernel binary
(or library as it may be). Which is in a way exactly my objection.

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.

But that really isn't how standalone mode works, and IMHO it also
doesn't match what tools are today.

johannes