On Wed, Apr 3, 2019 at 10:20 AM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > > On Wed, Apr 03, 2019 at 04:48:37PM +0900, Masahiro Yamada wrote: > > On Thu, Mar 28, 2019 at 2:32 AM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > > > > > > On Mon, Mar 25, 2019 at 09:49:47AM -0400, Joel Fernandes wrote: > > > > On Thu, Feb 14, 2019 at 07:19:29PM -0800, Alexei Starovoitov wrote: > > > > > On Mon, Feb 11, 2019 at 09:35:59AM -0500, Joel Fernandes (Google) wrote: > > > > > > Introduce in-kernel headers and other artifacts which are made available > > > > > > as an archive through proc (/proc/kheaders.txz file). This archive makes > > > > > > it possible to build kernel modules, run eBPF programs, and other > > > > > > tracing programs that need to extend the kernel for tracing purposes > > > > > > without any dependency on the file system having headers and build > > > > > > artifacts. > > > > > > > > > > > > On Android and embedded systems, it is common to switch kernels but not > > > > > > have kernel headers available on the file system. Raw kernel headers > > > > > > also cannot be copied into the filesystem like they can be on other > > > > > > distros, due to licensing and other issues. There's no linux-headers > > > > > > package on Android. Further once a different kernel is booted, any > > > > > > headers stored on the file system will no longer be useful. By storing > > > > > > the headers as a compressed archive within the kernel, we can avoid these > > > > > > issues that have been a hindrance for a long time. > > > > > > > > > > The set looks good to me and since the main use case is building bpf progs > > > > > I can route it via bpf-next tree if there are no objections. > > > > > Masahiro, could you please ack it? > > > > > > > > FYI, Masahiro's comments were all address by v5: > > > > https://lore.kernel.org/patchwork/project/lkml/list/?series=387311 > > > > > > > > I believe aren't more outstanding concerns. Could we consider it for v5.2? > > > > > > Just to highlight the problem, today I booted v5.0 on an emulated Android > > > device for some testing, that didn't have a set of prebuilt headers that we > > > have been packaging on well known kernels, to get around this issue. This > > > caused great pain and issues with what I was doing. I know me and many others > > > really want this. With this I can boot an emulated Android device with > > > IKCONFIG_PROC=y and run BCC with that that. Also I want to do the BCC side of > > > the development, but first want to know if we can merge this upstream. > > > > > > Masahiro, I believe due diligence has been done in solidifying it as posted > > > in the v5. Anything else we need to do here? Are you with the patches? > > > > > > As you said, these updates are "cosmetic". > > Nobody is worried about (or interested in) them. > > Even if we miss something, they are fixable later. > > > > I accept embedding headers in the kernel, > > but I do not like the part about external module build. > > - kernel embeds build artifacts that depend on a > > particular host-arch > > - users do not know which compiler to use > > Perhaps, you may remember my concerns. > > https://lore.kernel.org/patchwork/patch/1046307/#1239501 > > Masahiro, > I think we already discussed this right. The compiler issue is a user-issue - > it is not a problem that has arisen because this patch. Anyone can build a > kernel module today without this patch - using a compiler that is different > from the running kernel. So I did not fully understand your concern. This > patch does not ship a compiler in the archive. The compiler is upto the user > based on user environment. They can already shoot themself in foot without > this patch. > > Greg, > Would be great to get your thoughts here as well about Masami's concern. > > Honestly, the "kernel module building artifacts" bit is a bonus with this > patch. The main thing we are adding or that we need is really the headers > (for BCC). I just thought shipping the kernel build artifacts would also be > awesome because people can now build kernel modules without needing a kernel > tree at all. > > But I also want this stuff merged so if folks are really unhappy with the > module build artifacts and only want headers - then that's also fine with me > and I can yank them - that would also mean though that this work cannot be a > replacement for linux-headers package on distros, so that would be sad. > > thanks! IMHO, including the module build stuff is fine, and the stuff that Masahiro mentions doesn't matter much. To be specific about the concerns: >> > > - kernel embeds build artifacts that depend on a > > particular host-arch What are these artifacts? We build the kernel as a standalone system. It's not as if we statically link host glibc into it or something. > > - users do not know which compiler to use Does that matter much? Do things ever break if the kernel proper is built with GCC x.y.z and we build a module with GCC x.y.(z+1)? Why would it? Structure layout is invariant across compiler version, or at least ought to be. And don't we have exactly the same problem with any kernel headers package? I don't think it'd hurt to include the output of $(CC) --version though. Like Joel, I'd like to see this change merged. It'll make life easier for a lot of people.
