On Thu, Oct 8, 2020 at 10:46 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > 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? > Half-joking, technically uml is not a kernel, it is a tool that simulates a kernel and it uses part of the Linux kernel to do that :) > > 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. > Leaving the library/standalone build itself aside for a while, do you agree that the various tools we are building with library mode should be placed in tools? Things like lklfuse - mounting Linux filesystems with fuse, or lklhijack.so - a preload library that intercept network/file system calls and routes them through the library mode. > 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. > Correct, this is my perspective. > But that really isn't how standalone mode works, and IMHO it also > doesn't match what tools are today. > What if we could use standalone mode for other purposes that would require creating a new binary in addition to the current linux binary?
