[RFC v7 00/21] Unifying LKL into UML

[Octavian Purdila]

On Thu, Oct 8, 2020 at 3:50 PM Anton Ivanov
<anton.ivanov at cambridgegreys.com> wrote:
>
>
> On 08/10/2020 13:12, Hajime Tazaki wrote:
> > Hello Anton,
> >
> > On Wed, 07 Oct 2020 22:30:03 +0900,
> > Anton Ivanov wrote:
> >>
> >> On 06/10/2020 10:44, Hajime Tazaki wrote:
> >>> This is another spin of the unification of LKL into UML.  Based on the
> >>> discussion of v4 patchset, we have tried to address issue raised and
> >>> rewrote the patchset from scratch.  The summary is listed in the
> >>> changelog below.
> >>>
> >>> Although there are still bugs in the patchset, we'd like to ask your
> >>> opinions on the design we changed.
> >>>
> >>> The milestone section is also updated: this patchset is for the
> >>> milestone 1, though the common init API is still not implemented yet.
> >>>
> >>>
> >>> Changes in rfc v7:
> >>> - preserve `make ARCH=um` syntax to build UML
> >>> - introduce `make ARCH=um UMMODE=library` to build library mode
> >>> - fix undefined symbols issue during modpost
> >>> - clean up makefiles (arch/um, tools/um)
> >> Hi Hajime, hi Tavi,
> >>
> >> Our starting point should be that it does not break the existing build. It still does.
> > I agree with the starting point.
> >
> >> If I build a "stock configuration" UML after applying the patchset
> >> the resulting vmlinux is not executable.
> > Ah, I confirmed the issue.
> > I was only trying to make the `linux` binary compatible, not vmlinux.
> >
> > Because vmlinux is now build as a relocatable object, this is
> > something we need to figure out if we wish to keep vmlinux executable.
> >
> > Do you think we should make vmlinux executable even if we have the
> > file linux executable ? If yes, we will work on this to fix the issue.
>
> In my opinion, any relocatable objects, etc should be clearly named - either .o, .so, etc depending on what they are. We should not try to reuse any of the existing files for a different purpose.
>
> I also agree with Johannes that we are not using the tools/ directory for its intended purpose.
>
> We are not trying to build a tool. We are trying to build a sub-architecture. IMHO, the build should use a subdirectory under arch/um.
>

Hi Anton, Johannes,

>From strictly the UML point of view, I can see how this would be a
sub-architecture build since we are doing both the kernel build and
the UML binary as a single step.

If we look at arch/um as just the kernel that enables many
applications, just one of which it is uml, I believe it is cleaner to
build specific applications elsewhere. That is why we proposed to do a
two step build process: one that builds the kernel as a relocatable
object and one that uses this object to build programs, shared
libraries, etc. Besides allowing us to create multiple tools /
applications it also makes it much easier to support multiple OSes or
other environments (e.g. bare-metal applications). As you can see,
this allowed us to remove the linker script for UML and instead just
used the target compiler to build the executable.

We have picked tools because it has the infrastructure to build
programs, shared libraries, and it is the single place (AFAIK) where
we don't link the code in there with the kernel binary.

Thanks,
Tavi