On Thu, 2020-10-08 at 23:53 +0300, Octavian Purdila wrote: > 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. Yeah, I guess that makes sense. I realize the line gets blurry ... OTOH, should these even live in the kernel tree? Almost seems like if the base lkl library is there, the other stuff might not really need to be, it's supposed to use the (stable) syscall API? Dunno. Not sure "doesn't need to be" really is an argument for "shouldn't be" anyway. > > 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? Anything specific you have in mind? But I still think that "UML standalone 'linux' binary" is something that seems like the kernel build system should be able do? If only to avoid regressions from what we have now ... johannes
