Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190118225543.86996-1-joel@joelfernandes.org>
 <20190119082532.GA9004@kroah.com> <20190119162754.GC231277@google.com>
 <CAKOZuet+7a4jdox6rebMN=kJtDn5RUYzvNjFh+Pzn2UkuP0Y8Q@mail.gmail.com>
 <20190119232503.GA149403@google.com> <78AACAF1-8EBF-4DF3-BE94-5B14E78BA791@zytor.com>
 <20190120155838.GA23827@google.com> <20190306230944.GB7915@amd>
In-Reply-To: <20190306230944.GB7915@amd>
From:   Daniel Colascione <dancol@google.com>
Date:   Wed, 6 Mar 2019 15:37:46 -0800
Message-ID: <CAKOZuetOePf89cXRkvmWeGnvG7zYN=SW1yyrZibuyOqZQFTGkg@mail.gmail.com>
Subject: Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel
To:     Pavel Machek <pavel@ucw.cz>
Cc:     Joel Fernandes <joel@joelfernandes.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>, ast@kernel.org,
        atish patra <atishp04@gmail.com>,
        Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
        Jan Kara <jack@suse.cz>, Jonathan Corbet <corbet@lwn.net>,
        Karim Yaghmour <karim.yaghmour@opersys.com>,
        Kees Cook <keescook@chromium.org>, kernel-team@android.com,
        "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
        Manoj Rao <linux@manojrajarao.com>,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        Paul McKenney <paulmck@linux.vnet.ibm.com>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>,
        Randy Dunlap <rdunlap@infradead.org>, rostedt@goodmis.org,
        Thomas Gleixner <tglx@linutronix.de>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        yhs@fb.com
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Mar 6, 2019 at 3:09 PM Pavel Machek <pavel@ucw.cz> wrote:
>
>
> > > >Ok, I'll look into LZMA. Thanks for checking the compression sizes.
> > > >
> > > >- Joel
> > >
> > > Don't use lzma, use xz if you are going to do something.
> >
> > Ok, sounds good.

XZ is a file format for LZMA2. Everyone's right. :-)

> >
> > > However, it seems unlikely to me that someone not willing to spend the space in the filesystem will spend unswappable kernel memory.
> > >
> > > It would seem that a far saner way to do this is to use inittmpfs or perhaps an auxiliary "ktmpfs" so it can at least be swapped out if you have swap.
> >
> > But this is already possible with the proposed solution, you would load the
> > module, extract it into a tmpfs, and unload the module. TMPFS pages can
> > already be swapped.
>
> So your licensing requirements prevent you from having headers in the
> filesystem, but allow module with the headers hidden inside on the
> filesystem?
>
> Looks like you should just tar xvzf
> this-is-a-kernel-module-I-promise.ko /usr/src/linux/include :-).

I just don't get the opposition to Joel's work. The rest of the thread
already goes into detail about the problems with pure-filesystem
solutions, and you and others are just totally ignoring those
well-thought-out rationales for the module approach and doing
inflooping on "lol just use a tarball". That's not productive.

Look; here's the bottom line: without this work, doing certain kinds
of system tracing is a nightmare, and with this patch, it Just Works.
You're arguing that various tools should do a better job of keeping
the filesystem in sync with the kernel. Maybe you're right. But we
don't live in a world where they will, because if this coherence were
going to happen, it'd work already. But this work solves the problem:
by necessity, anything that changes a kernel image *must* update
modules coherently, whether the kernel image and module come from the
filesystem, network boot, some kind of SQL database, or carrier
pigeon. There's nothing wrong with work that very cheaply makes the
kernel self-describing (introspection is elegant) and that takes
advantage of *existing* kernel tooling infrastructure to transparently
do a new thing.

You don't have to use this patch if you don't want to. Please stop
trying to block it.