All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	ast@kernel.org, atishp04@gmail.com,
	Borislav Petkov <bp@alien8.de>,
	dancol@google.com, "H. Peter Anvin" <hpa@zytor.com>,
	Ingo Molnar <mingo@redhat.com>, Jan Kara <jack@suse.cz>,
	Jonathan Corbet <corbet@lwn.net>,
	karim.yaghmour@opersys.com, Kees Cook <keescook@chromium.org>,
	kernel-team@android.com, linux-doc@vger.kernel.org,
	Manoj Rao <linux@manojrajarao.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	paulmck@linux.vnet.ibm.com,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	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
Subject: Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel
Date: Sat, 19 Jan 2019 11:26:44 -0500	[thread overview]
Message-ID: <20190119162644.GA231277@google.com> (raw)
In-Reply-To: <20190119103606.GA17400@kroah.com>

On Sat, Jan 19, 2019 at 11:36:06AM +0100, Greg KH wrote:
> On Sat, Jan 19, 2019 at 02:28:00AM -0800, Christoph Hellwig wrote:
> > This seems like a pretty horrible idea and waste of kernel memory.
> 
> It's only a waste if you want it to be a waste, i.e. if you load the
> kernel module.
> 
> This really isn't any different from how /proc/config.gz works.

Yes, that's right, it can be built as a module and loaded and unloaded on
demand to free the kernel memory. Also such a module can be made a part of
the initrd image itself (like other kernel modules that are built into an
initrd), so this solution is already initrd-ready if anyone really wants it
that way.

> > Just add support to kbuild to store a compressed archive in initramfs
> > and unpack it in the right place.
> 
> I think the issue is that some devices do not use initramfs, or switch
> away from it after init happens or something like that.  Joel has all of
> the looney details that he can provide.

Initially I had written this as an image embedded into an init section,
similar to the initramfs. On boot if a boot argument was passed, then the
archive embedded was allocated additional non-init kernel memory to store it for
retrieval through /proc. After that, the image that's embedded would be
dropped entirely as its init memory. If no boot argument was passed, then no
additional memory is used at all. Even though I got that working, I decided
not to go with it because it was clunky because: 1. It required modification
of the linker scripts in the kernel to embed the image into the init section,
and also required a boot argument to be passed which makes the decision on
whether to have headers as a boot-time decision than a post-boot decision.
For these reasons, it is much cleaner to just have a loadable module and make
it on-demand, as I am doing in this patch similar to what /proc/config.gz
does.

thanks!

 - Joel


  reply	other threads:[~2019-01-19 16:27 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 22:55 [RFC] Provide in-kernel headers for making it easy to extend the kernel Joel Fernandes
2019-01-19  8:25 ` Greg KH
2019-01-19 16:27   ` Joel Fernandes
2019-01-19 17:43     ` Daniel Colascione
2019-01-19 23:25       ` Joel Fernandes
2019-01-19 23:44         ` hpa
2019-01-20 15:58           ` Joel Fernandes
2019-03-06 23:09             ` Pavel Machek
2019-03-06 23:37               ` Daniel Colascione
2019-03-07  0:07                 ` H. Peter Anvin
2019-03-07  0:33                   ` Daniel Colascione
2019-03-07  1:22                     ` Enrico Weigelt, metux IT consult
2019-03-07  1:49                       ` Daniel Colascione
2019-03-07 20:41                         ` Enrico Weigelt, metux IT consult
2019-03-07 20:55                           ` Greg KH
2019-03-07 22:11                             ` Enrico Weigelt, metux IT consult
2019-03-07 23:12                               ` Joel Fernandes
2019-03-07 23:40                                 ` hpa
2019-03-08  3:16                                   ` Joel Fernandes
2019-03-07  1:42                   ` Joel Fernandes
2019-03-07 16:24                     ` Enrico Weigelt, metux IT consult
2019-03-07  0:32                 ` H. Peter Anvin
2019-03-07  0:36                   ` Daniel Colascione
2019-03-07  0:42               ` Enrico Weigelt, metux IT consult
2019-03-07  1:48                 ` Joel Fernandes
2019-03-07 17:37                   ` Enrico Weigelt, metux IT consult
2019-01-19  8:26 ` Greg KH
2019-01-19 16:27   ` Joel Fernandes
2019-01-19 10:28 ` Christoph Hellwig
2019-01-19 10:36   ` Greg KH
2019-01-19 16:26     ` Joel Fernandes [this message]
2019-01-20  7:01     ` hpa
2019-01-20 16:10       ` Joel Fernandes
2019-01-20 21:58         ` hpa
2019-01-21  1:45           ` Joel Fernandes
2019-01-21  2:49             ` hpa
2019-01-21  4:38               ` Sandeep Patil
2019-01-22 13:39               ` Joel Fernandes
2019-01-23 21:29                 ` Karim Yaghmour
2019-01-23 22:37                   ` Daniel Colascione
2019-01-24  2:32                     ` Joel Fernandes
2019-01-24 14:18                       ` Joel Fernandes
2019-01-24 18:57                     ` Karim Yaghmour
2019-01-24 20:59                       ` Joel Fernandes
2019-01-25 19:00                         ` hpa
2019-01-25 19:15                           ` Daniel Colascione
2019-01-25 19:51                             ` hpa
2019-01-25 20:34                               ` Daniel Colascione
2019-01-25 20:46                                 ` Joel Fernandes
2019-01-25 20:28                           ` Joel Fernandes
2019-03-06 23:09 ` Pavel Machek
2019-03-06 23:35   ` H. Peter Anvin
2019-01-26 12:05 Norbert Lange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190119162644.GA231277@google.com \
    --to=joel@joelfernandes.org \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=atishp04@gmail.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dancol@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=hpa@zytor.com \
    --cc=jack@suse.cz \
    --cc=karim.yaghmour@opersys.com \
    --cc=keescook@chromium.org \
    --cc=kernel-team@android.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@manojrajarao.com \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yamada.masahiro@socionext.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.