
Shrinking the kernel with a hammer - rbanffy
https://lwn.net/SubscriberLink/748198/6fa400001570fb39/
======
buserror
I think that battle has been lost a while back. Given the 1) dislike of
'conditional code' in the kernel and 2) the use of device tree, there is no
longer any possibility for the compiler/linker to remove stuff that isn't
actually needed.

I think the big vendors are to blame, they've been dreaming about a single
kernel binary that can run on ANY board, with a magic device tree, it suits
their own way of 'distributing' SDKs, and it has transformed the kernel from
something that you COULD tune to a platform/board to one that is /actively/
discouraged to be tuned to a platform.

A while back a couple of friends and I reverse engineered a 4MB picture frame
[0], and had linux and doom running on it, for the lulz. That was kernel 2.6;
these days imagining running linux in 4MB makes me sniggers.

[0]:
[https://sites.google.com/site/repurposelinux/df3120](https://sites.google.com/site/repurposelinux/df3120)

~~~
simias
You're being too dismissive IMO. Do you really want the linux kernel to focus
mainly on 4MB picture frames at the expense of everybody else? As an embedded
dev I very much welcomed the device tree, having to create a billion
variations of the same BSP to support various configurations was not fun.
"Conditional code" is more prone to bitrot than anything else since you have
to test a bunch of different configurations if you want to make sure that it
even still compiles correctly.

Besides you're still free to make your own single purpose micro-optimized
kernel with only the drivers you want if you feel like it.

I can believe that today's kernel is harder to get to work decently on a 4MB
picture frame than in the past. On the other hand it's a lot easier to work
with modern embedded SoCs. I think it's a worthy trade-off and a very good
pragmatical decision.

~~~
buserror
I actually disagree.

I will take 100% of the time a kernel that /doesn't compile/ because an option
has been set that had 'bitrotted' than a kernel that compiles with the same
code in a "if (my device tree flag)" block that in fact is _equally borken_
but you'll never know, until days/weeks of debugging to figure out that bit
_was_ rotten, and nobody had tested it for years until you.

And in the meantime, that code was rotten, and rolled in in every phone and
servers on the planet for absolutely no reason.

At least, when you decide that CONFIG_ARCH_TOASTER is no longer supported, you
CAN trim the code out easily. You can't do that with code that is living in
shadows.

~~~
simias
Code that's dynamically disabled is at least checked by the compiler, you can
detect a whole bunch of errors that way (function prototypes changing, using
deprecated APIs, naming clashes etc...). Of course bitrot will always happen
if code is never tested but code that's never actually _built_ will rot much,
much faster in my experience.

Then some day one poor sod actually wants to use the option, he gets 4 pages
of compilations error and decides maybe he didn't need that after all. Code
that compiles doesn't necessarily work but it's a start...

>At least, when you decide that CONFIG_ARCH_TOASTER is no longer supported,
you CAN trim the code out easily. You can't do that with code that is living
in shadows.

I suppose you're right but again, I feel like you're optimizing for the wrong
thing. For one thing the linux kernel is not too keen on removing stuff in my
experience, in general older APIs coexist with newer ones and board support is
not dropped willy-nilly.

Beyond that I don't know if I should trust my judgement over yours but I'm
sure I'll trust the kernel maintainer's judgement over both of ours.

~~~
ilammy
> _Code that 's dynamically disabled is at least checked by the compiler_

You can still trivially ensure that kernel with CONFIG_ARCH_TOASTER compiles
fine by setting up a build server which automatically checks each and every
option.

~~~
simias
You don't just need to check any single option, you also need to check every
combination of options that might reasonably get used together to make sure
that it's handled properly. Given the size of the kernel and its thousands of
configuration options testing all viable combinations is not reasonable.

------
zoobab
I still have 6x USR2450, one of the first router where you could flash Linux
(2.4.20). It had 4MB RAM and 1MB flash, 10mbps, rs232, and it was quite some
sport to add a feature there.

You could run LinuxAP on there:

[https://github.com/zoobab/linuxAP-eh](https://github.com/zoobab/linuxAP-eh)

------
jxub
This has a Nieztschean tint. When you have a hammer, everything looks like a
Linux 4.2.0 kernel, erm, nail.

------
hguhghuff
How small did it get? But hard to find.....

~~~
sp332
Previous installments in the series were about shrinking the file size.
[https://lwn.net/Articles/741494/](https://lwn.net/Articles/741494/)
[https://lwn.net/Articles/744507/](https://lwn.net/Articles/744507/)
[https://lwn.net/Articles/746780/](https://lwn.net/Articles/746780/) This one
is about shrinking RAM usage.

