[RFC v7 00/21] Unifying LKL into UML

[Octavian Purdila]

On Thu, Oct 8, 2020 at 8:18 PM Anton Ivanov
<anton.ivanov at cambridgegreys.com> wrote:
>
> On 08/10/2020 18:13, Octavian Purdila wrote:
> > 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.
>
> I have no objection to the proposal. In fact I like it very much.
>
> My only concern is that we end up with files which are named identically
> to already existing ones.
>
> IMHO, the kernel relocatable object should be vmlinux.a or vmlinux.so or
> vmlinux.o. It should not replace an already existing file which behaves
> differently.
>

Got it, we will change that for the next patch series.