All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jari Ruusu <jariruusu@protonmail.com>,
	Salvatore Bonaccorso <carnil@debian.org>,
	Sasha Levin <sashal@kernel.org>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	Jiri Slaby <jirislaby@kernel.org>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: glibc VETO for kernel version SUBLEVEL >= 255
Date: Sun, 26 Sep 2021 17:03:29 +0200	[thread overview]
Message-ID: <20210926150329.GA13506@1wt.eu> (raw)
In-Reply-To: <YVBb9ZoDGgV4cbXb@kroah.com>

On Sun, Sep 26, 2021 at 01:39:33PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Sep 26, 2021 at 11:31:20AM +0000, Jari Ruusu wrote:
> > On Sunday, September 26th, 2021 at 14:24, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > Why use an older kernel tree on this device? Rasbian seems to be on
> > > 4.19.y at the least right now, is there something in those older kernel
> > > trees that you need?
> > 
> > Due to circumstances, I need "smallest possible" kernel with all extra
> > stripped out. 4.9.y kernels are smaller than newer ones.
> 
> Smaller by how much, and what portion grew?  Are we building things into
> the kernel that previously was able to be compiled out?  Or is there
> something new added after 4.9 that adds a huge memory increase?
> 
> Figuring that out would be good as you only have 1 more year for 4.9.y
> to be alive, that's not going to last for forever...

FWIW a situation I faced a few times was trying to put a modern kernel
on a small NAND partition of an older device. Nowadays kernels are really
big. I don't have numbers here but for example I never managed to make a
5.10 fit into the 4 MB partition of an old armv5 device where its 3.4 had
plenty of room. And there isn't a single thing to disable, it looks more
like a systemic growth, probably due to all the stuff we now have to
improve large systems performance and harden everything.

Willy

  reply	other threads:[~2021-09-26 15:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-26  7:23 glibc VETO for kernel version SUBLEVEL >= 255 Jari Ruusu
2021-09-26  7:28 ` Greg Kroah-Hartman
2021-09-26  8:10   ` Salvatore Bonaccorso
2021-09-26  9:29     ` Greg Kroah-Hartman
2021-09-26 10:58       ` Jari Ruusu
2021-09-26 11:24         ` Greg Kroah-Hartman
2021-09-26 11:31           ` Jari Ruusu
2021-09-26 11:39             ` Greg Kroah-Hartman
2021-09-26 15:03               ` Willy Tarreau [this message]
2021-09-26 16:18               ` Jari Ruusu

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=20210926150329.GA13506@1wt.eu \
    --to=w@1wt.eu \
    --cc=aurelien@aurel32.net \
    --cc=carnil@debian.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jariruusu@protonmail.com \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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.