LWN: Comments on "Shrinking the kernel with an axe"

LTO doesn't guarantee anything

davez — Thu, 22 Feb 2018 13:26:51 +0000

Just a reminder that LTO doesn't guarantee anything. One should always verify that LTO yields the desired result, be it smaller files or better performance. The output quality of LTO often just depends on inlining tradeoffs in the compiler.

Shrinking the kernel with an axe

snajpa — Thu, 15 Feb 2018 21:37:32 +0000

Let me just thank you for this effort, I and folks at base42 hackerspace appreciate it a lot. We’re looking forward to being able to spawn new projects at tubo speed, thanks to all the frameworks already available in Linux.
Whether it’s stm32 or pic32, single package Linux with industrial temp ranges is something we’re missing right now.

Shrinking the kernel with an axe

smoogen — Thu, 15 Feb 2018 02:29:50 +0000

Having looked through the hell that anyone who signs up for TTY layer maintenance has to take from every developer and other kernel developer when some fix broke their app... I almost think rejecting mintty was a "Listen kid, no really listen, you don't want to go in there. They ate Alan Cox alive.. they burnt out a couple more people. Just keep you liver and sanity and do this as your own project."

Shrinking the kernel with an axe

pr1268 — Mon, 12 Feb 2018 10:14:38 +0000

I propose that all SoC's these days be built with Arm64's. Kernel 4.16's support for 52-bit physical addresses on this arch/HW makes Nicolas' efforts moot. (Just kidding.)

Seriously, though, I still wonder sometimes how much benefit might be realized by Mr. Pitre's work. At least if not for the size savings, then perhaps for the reduced attack vector of undiscovered vulnerabilities?

Shrinking the kernel with an axe

vegard — Mon, 12 Feb 2018 07:12:06 +0000

minitty should be easily justified for security reasons. The TTY layer still has unfixed bugs that are easy to hit using syzkaller and apparently nobody is able (or willing) to wade through the mess of locking and ownership to figure it out.

Shrinking the kernel with an axe

bandrami — Mon, 12 Feb 2018 03:07:00 +0000

That may be fbterm you're thinking of?

https://github.com/dvdhrm/kmscon/wiki/FAQ

Putting the entire VT stack in userland was the original reason for developing it.

Shrinking the kernel with an axe

josh — Mon, 12 Feb 2018 00:12:07 +0000

To the best of my knowledge, kmscon just worked like a terminal emulator, and it still required a pty device.

Executing from on-chip flash memory

jreiser — Sun, 11 Feb 2018 16:41:29 +0000

... an amount of on-chip flash memory that is typically a few times larger than the on-chip RAM. Such on-chip flash memory also might be a few times slower than on-chip RAM.

Shrinking the kernel with an axe

dirtyepic — Sat, 10 Feb 2018 08:17:18 +0000

Gentoo has built-in support for cross compiling using crossdev. It's all integrated into the package manager so building binaries for another architecture is no different than building for the native system. There are also profiles for things like uClibc/musl if you want to go that direction.

https://wiki.gentoo.org/wiki/Embedded_Handbook
https://wiki.gentoo.org/wiki/Cross_build_environment

If you're just looking to offload compiling to a machine of the same architecture that has more resources, then Portage can be set up to use distcc as easily as setting a couple config options.

I have to disagree with the parent comment. Gentoo's main selling point is its flexibility. It lets you build a system that has exactly what you need and nothing more. In other words, it's shrinking the distro with an axe. If anything performance is just a side effect of the method it uses to accomplish this.

Of course, Gentoo's main downfall is also its flexibility. It turns out that building a system that has exactly what you need requires you to know exactly what you need first.

Shrinking the kernel with an axe

npitre — Sat, 10 Feb 2018 02:19:58 +0000

The word I get from microcontroller vendors (the marketing guys that is -- the engineers disagree) is that they have no demand for Linux support. What individual users or groups should do is to signal their interest to their vendor. If the market demand is there then I will no longer be the only one being paid to work on this, and upstream inclusion would be easier to advocate. Those articles are nice for sharing my knowledge and experience, but this is also an attempt at stirring up some interest or I'll eventually be paid to work on something else.

If the market demand is there, then mainline acceptance becomes a purely technical issue. So far in my experience I always managed to sort out technical issues with upstream maintainers, but when they ask if the added maintenance burden is justified by an actual user base then they have a point.

I think the issues with PaX/grsecurity are different. I'm not familiar enough with it to venture further comments though.

Shrinking the kernel with an axe

rbrito — Fri, 09 Feb 2018 22:59:55 +0000

I just skimmed the front page of https://buildroot.org/ and it looks very interesting indeed.

Even some smaller/older desktops may benefit from this (and I have some).

Shrinking the kernel with an axe

rbrito — Fri, 09 Feb 2018 22:56:13 +0000

Thanks for the reply.

The idea here would be to build on a machine that has more RAM and, then, use the packages on that NAS...

I don't know how easy Gentoo makes building and then transferring the packages/programs to another machine, though (or, perhaps, cross-compiling).

I would appreciate any comments on that.

Shrinking the kernel with an axe

vadim — Fri, 09 Feb 2018 22:00:14 +0000

Gentoo is likely unsuitable for such a purpose. Gentoo builds from source, and needs large amounts of processing power and memory to work usably. Gentoo's main selling point is eking out the last 5% of performance by optimizing for your specific configuration, but the way it works fits high end hardware best. With a 64MB RAM box chances are gcc or g++ will try allocating far more than that when building something big, and the entire machine will die from a lack of memory.

That wouldn't really solve the problem anyway. To be secure in modern times you need to run modern software and not the swiss cheese from a decade ago. Modern software expects to be built in a modern, powerful desktop oriented environments, recent versions of gcc, etc. Something like Gentoo might be able to trim the fat somewhat, but current software is just fatter than the early versions were.

Shrinking the kernel with an axe

Lionel_Debroux — Fri, 09 Feb 2018 21:27:39 +0000

Your reasoning for reducing the footprint of the Linux kernel through simplified versions of the layers, which would enable Linux to target platforms it currently can't for technical reasons, and arguably help further lower the market share of the (partially) closed-source offerings (with GPL'ed software, even, though that's getting less popular), made perfect sense to me. It's probably even more relevant now, with the advent of efforts such as NERF... Hopefully, the simplified code would also provide lower attack surface.

But how can individual users, or scattered groups thereof, efficiently signal their interest for e.g. tinified versions of the standard Linux kernel features - or, as far as I'm concerned, various features, fixes and improvements known from PaX/grsecurity, and other people have other interests - to the powers that be among the main Linux kernel maintainers ?

Maintaining, evolving, testing out of tree Linux kernel code (theoretically less political interference, more technical work, but also clearly zero decision weight) over the long term is known to be exhausting - especially when done unpaid or under-paid on one's free time, as happens to most FLOSS maintainers...

Shrinking the kernel with an axe

oldnpastit — Fri, 09 Feb 2018 20:21:13 +0000

To keep userland size under control you might want to look at buildroot.

Great article by the way, thanks!

Shrinking the kernel with an axe

flussence — Fri, 09 Feb 2018 19:05:51 +0000

It seems abandoned. Would've been nice if it had gained popularity, since the other thing it had was OpenGL hardware rendering. The built in fbcon is abysmally slow to the point where you can slice seconds off boot time by just passing "quiet" on the cmdline.

Shrinking the kernel with an axe

npitre — Fri, 09 Feb 2018 17:03:38 +0000

Thank you for your comment. Your observation is quite right, especially about interested users. The rest normally comes along with them.
These articles are a way for this work not to completely go to waste.

Shrinking the kernel with an axe

rbrito — Fri, 09 Feb 2018 16:58:35 +0000

Super thanks for this amazing series! Please, keep up with it!

I have a small NAS here (a KuroBox HD, that is a powerpc machine) that only has 64MB of memory and not only the kernel is getting bigger all the time (even with equivalent configurations), but the userspace is getting larger each time.

I think that it is time to drop distributions like Debian for such machines and switch to something like Arch or Gentoo (even though I know nothing about them), since the lots of dependencies that they pull in I will never use.

This kernel work that you're showing is also likely to make booting speedier, if I understand things right.

Thanks once again!

Shrinking the kernel with an axe

Lionel_Debroux — Fri, 09 Feb 2018 15:56:58 +0000

Getting changes like these in mainline requires time, money, energy, probably a sufficient number of interested users, and possibly overcoming some non-technical obstacles. Likewise for long-term maintenance of the simpler code paths after mainline integration. With the lukewarm reception of the initial attempts, I can understand why he's not eager to do it :)
But I'm still glad that he's spending time making this series of quality articles for LWN.

Shrinking the kernel with an axe

bandrami — Fri, 09 Feb 2018 15:32:45 +0000

Whatever happened to kmscon? Wasn't the whole point of that that you could skip all of CONFIG_VT and let userland handle the line discipline? (It got famous because it could display Unicode on the console, but IIRC that was just a bonus)

Shrinking the kernel with an axe

smurf — Fri, 09 Feb 2018 12:32:28 +0000

If the "dumb" serial input needs to support a shell, you still need a small(ish) line discipline.
Too bad the effort to include minitty got blocked, IMHO these days nobody still needs the full-scale TTY subsystem with its ancient and intractable code base. Hopefully it can be revived.

Shrinking the kernel with an axe

pclouds — Fri, 09 Feb 2018 07:42:51 +0000

> those attempts were welcomed with a cold headwind that left me alone in the woods with frozen fingers.

Poor Nico. I hope you keep trying and get these in mainline eventually.

Shrinking the kernel with an axe

josh — Fri, 09 Feb 2018 04:45:02 +0000

> The CRC32 checksum implementation is not small; fortunately, a smaller alternative is available:

Please submit a patch to make this the default in tinyconfig. (Or, ideally, to adapt the kernel configuration to add a CONFIG_CRC32_OPTIMIZED that's default y, depends on EXPERT, and gates the optimized implementations, so that this happens automatically rather than hardcoding it in tiny.config.)

> Consider another possible opportunity for size reduction: the TTY layer.

You can compile *out* the entire TTY layer. Perhaps we could introduce a minimal serial driver that doesn't implement TTY at all, and just provides a trivial character device. Or implement an input-capable version of earlyprintk.