All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Daniel Colascione <dancol@google.com>
Cc: Karim Yaghmour <karim.yaghmour@opersys.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Christoph Hellwig <hch@infradead.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>,
	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
Subject: Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel
Date: Thu, 24 Jan 2019 09:18:20 -0500	[thread overview]
Message-ID: <20190124141820.GA75378@google.com> (raw)
In-Reply-To: <20190124023216.GA75730@google.com>

On Wed, Jan 23, 2019 at 09:32:16PM -0500, Joel Fernandes wrote:
> On Wed, Jan 23, 2019 at 02:37:47PM -0800, Daniel Colascione wrote:
> > On Wed, Jan 23, 2019 at 1:29 PM Karim Yaghmour
> > <karim.yaghmour@opersys.com> wrote:
> [...]
> > > Personally I advocated a more aggressive approach with Joel in private:
> > > just put the darn headers straight into the kernel image, it's the
> > > *only* artifact we're sure will follow the Android device whatever
> > > happens to it (like built-in ftrace).
> > 
> > I was thinking along similar lines. Ordinarily, we make loadable
> > kernel modules. What we kind of want here is a non-loadable kernel
> > module --- or a non-loadable section in the kernel image proper. I'm
> > not familiar with early-stage kernel loader operation: I know it's
> > possible to crease discardable sections in the kernel image, but can
> > we create sections that are never slurped into memory in the first
> > place? If not, maybe loading and immediately discarding the header
> > section is good enough.
> 
> I am happy to see if I can shrink it down further. Especially using xz and
> stripping all comments period. I am optimistic this can be brought down
> further to a point where it would make sense to everyone to build it into the
> kernel. Lets see.
> 
> Last time I stripped comments, it went down by ~40%. What I haven't tried is
> doing this *with* xz compression. I am also open to brainstorming what else
> can be stripped.

Removing comments (/* */) with xz compression brings it down to 3.3MB.

thanks,

 - Joel


  reply	other threads:[~2019-01-24 14:18 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
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 [this message]
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=20190124141820.GA75378@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.