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

[Octavian Purdila]

On Wed, Oct 7, 2020 at 6:20 PM Johannes Berg <johannes at sipsolutions.net> wrote:
>

Hi Johannes,

Thank you for the review.

> 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.

The current UML build is already partially split. USER_OBJS build with
a different rule set than the rest of the kernel objects. IMHO this
change just makes this more clear and streamlined, especially with
regard to linking.

>
> >  tools/um/uml/Build                            | 48 +++++++++++++++++++
> >  tools/um/uml/drivers/Build                    | 10 ++++
>
> Also, what's with the names here? What's wrong with "Makefile"?
>
>

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

> I'm also not sure I see how this is built at all from the top level
> Makefile? Oh. I think Anton said it doesn't ... that alone would be a
> reason not to do it I guess.
>
>
> So why do you think it must be under tools/? Even if you consider "lkl"
> a "tool", that doesn't mean it must be there. I also consider a UML
> binary ("linux") a "tool" in my simulation environment, etc.
>
>
> And even LKL, which is the eventual goal here - why would you consider
> that a "tool"? I don't think we should.
>

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.