• J
    Provide in-kernel headers to make extending kernel easier · 43d8ce9d
    Joel Fernandes (Google) 提交于
    Introduce in-kernel headers which are made available as an archive
    through proc (/proc/kheaders.tar.xz file). This archive makes it
    possible to run eBPF and other tracing programs that need to extend the
    kernel for tracing purposes without any dependency on the file system
    having headers.
    
    A github PR is sent for the corresponding BCC patch at:
    https://github.com/iovisor/bcc/pull/2312
    
    On Android and embedded systems, it is common to switch kernels but not
    have kernel headers available on the file system. Further once a
    different kernel is booted, any headers stored on the file system will
    no longer be useful. This is an issue even well known to distros.
    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 best way to use this feature is by building it in. Several users
    have a need for this, when they switch debug kernels, they do not want to
    update the filesystem or worry about it where to store the headers on
    it. However, the feature is also buildable as a module in case the user
    desires it not being part of the kernel image. This makes it possible to
    load and unload the headers from memory on demand. A tracing program can
    load the module, do its operations, and then unload the module to save
    kernel memory. The total memory needed is 3.3MB.
    
    By having the archive available at a fixed location independent of
    filesystem dependencies and conventions, all debugging tools can
    directly refer to the fixed location for the archive, without concerning
    with where the headers on a typical filesystem which significantly
    simplifies tooling that needs kernel headers.
    
    The code to read the headers is based on /proc/config.gz code and uses
    the same technique to embed the headers.
    
    Other approaches were discussed such as having an in-memory mountable
    filesystem, but that has drawbacks such as requiring an in-kernel xz
    decompressor which we don't have today, and requiring usage of 42 MB of
    kernel memory to host the decompressed headers at anytime. Also this
    approach is simpler than such approaches.
    Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
    Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    43d8ce9d
Kconfig 65.5 KB