Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Date: Fri, 8 Mar 2019 15:02:51 +0100
- Cc: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Alexei Starovoitov <ast@xxxxxxxxxx>, atish patra <atishp04@xxxxxxxxx>, Daniel Colascione <dancol@xxxxxxxxxx>, Dan Williams <dan.j.williams@xxxxxxxxx>, Dietmar Eggemann <dietmar.eggemann@xxxxxxx>, Guenter Roeck <groeck@xxxxxxxxxxxx>, Jonathan Corbet <corbet@xxxxxxx>, Karim Yaghmour <karim.yaghmour@xxxxxxxxxxx>, Kees Cook <keescook@xxxxxxxxxxxx>, Android Kernel Team <kernel-team@xxxxxxxxxxx>, "open list:DOCUMENTATION" <linux-doc@xxxxxxxxxxxxxxx>, "open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@xxxxxxxxxxxxxxx>, linux-trace-devel@xxxxxxxxxxxxxxx, Manoj Rao <linux@xxxxxxxxxxxxxxxx>, Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>, Masami Hiramatsu <mhiramat@xxxxxxxxxx>, Qais Yousef <qais.yousef@xxxxxxx>, Randy Dunlap <rdunlap@xxxxxxxxxxxxx>, Steven Rostedt <rostedt@xxxxxxxxxxx>, Shuah Khan <shuah@xxxxxxxxxx>, Yonghong Song <yhs@xxxxxx>
- In-reply-to: <CAEXW_YQUcA+bnav20tAFQPXYE=epMie4X85diudKs_s-TJ7dsw@mail.gmail.com>
- References: <20190301160856.129678-1-joel@joelfernandes.org> <CAMuHMdU77UyUs-LvRx-NN_k0Y7MZXQkBdgL2i83veCkvdzeeqA@mail.gmail.com> <20190307150343.GB258852@google.com> <CAMuHMdW_7BTZREsnz7uMTToCZ4HDOZboMJH8k8UZica2pB=Jew@mail.gmail.com> <CAEXW_YQUcA+bnav20tAFQPXYE=epMie4X85diudKs_s-TJ7dsw@mail.gmail.com>
- User-agent: Mutt/1.11.3 (2019-02-01)
On Fri, Mar 08, 2019 at 05:42:32AM -0800, Joel Fernandes wrote:
> HI Geert,
>
> On Fri, Mar 8, 2019, 3:53 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > > It is just so much easier to use tar + xz at build time, and leave the
> > > decompression task to the user. After decompression, the files will live on
> > > the disk and the page-cache mechanism will free memory when/if the files fall
> > > off the LRUs.
> >
> > I'm also considering how generic and extensible the solution is.
> > What if people need other build artifacts in the future (e.g. signing key to
> > load signed modules)?
>
> That sounds like it could be useful. I don't see any reason off the
> top why that would not be possible to add to the list of archived
> files in the future. The patch allows populating the list of files
> from Kbuild using ikh_file_list variable.
Um, no, you don't want the signing key in the kernel itself, as that
totally defeats the purpose of the signing key :)
greg k-h
[Index of Archives]
[Linux USB Development]
[Linux USB Development]
[Linux Audio Users]
[Yosemite Hiking]
[Linux Kernel]
[Linux SCSI]