On Thu, Oct 8, 2020 at 8:18 PM Anton Ivanov <anton.ivanov@xxxxxxxxxxxxxxxxxx> wrote: > > On 08/10/2020 18:13, Octavian Purdila wrote: > > On Thu, Oct 8, 2020 at 3:50 PM Anton Ivanov > > <anton.ivanov@xxxxxxxxxxxxxxxxxx> 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.
