Starting a new thread because I don't want to shit up the one this came up in...

Starting a new thread because I don't want to shit up the one this came up in, but how many of Linux's 15+ million lines could be stripped out and still have a perfectly useful kernel? How much of that is some weird esoteric architecture or redundant fixes for problems caused by redundant code interacting? Is x86 really that complicated?

Other urls found in this thread:

reddit.com/r/linux/comments/2ny1lz/im_greg_kroahhartman_linux_kernel_developer_ama/cmi8udx
twitter.com/NSFWRedditVideo

why did the code grow so rapidly near 3.0.14?

Can you name another CPU family where the memory management requires you to be proficient in octal?

More drivers.

Dunno. That was something I brought up in the last thread. The number of comments with "shits" vs "craps" spiked, too, as did the total number of "fucks". Something was pissing the devs off.

The bloat is mostly drivers and shit that needs to be in kernel but is only useful on some machines.

A lot. Which is why it comes with a configuration utility for doing exactly that.

You could strip out a lot, but it depends on what you define as 'usable', and what you want to use it on.

For example, you could strip out hundreds of CPU architectures and keep the big ones. But a key thing to remember is that you aren't running all 15-20 million lines on your PC. When you compile the kernel it skips a huge amount of things you don't need.

If it's the final output you care about, then you want to start murdering things like filesystem code, which may be present regardless of use.

To answer OP, yes x86 is complex, but not 1M lines complex, you could probably implement most of it in 100K lines.

I've made a kernel in x86, I don't know what you are talking about.

Well of course you could get rid of all the code supporting ARM and x64 and still have a usable x86 kernel codebase.
A lot of the code will be drivers for esoteric devices and features that you don't use. If you don't use ext2 or USB then of course you can remove those codepaths and still have a working system.

I found Linux from 2.0+ to be perfectly functional, had to fuck around a fair bit more for USB, but they weren't common then anyway

I do x86 assembly and I've never touched octals in my life.

Terry?

Never managed pagetables by hand?

No, but I'm a big fan


There is nothing intrinsically "Octal" about pagetables, they can be handled in hexadecimal just fine.

In theory, you can strip down the Linux kernel all the way down to vmlinuz, the actual kernel executable itself in compressed form, and the init system to decompress vmlinuz and initialize hardware. Which would in theory give you an extremely small and rather useless Linux install of a couple megabytes at most

More complex architecture usually equates to less code in fact, assuming you know how to optimize your shit. Its always RISC = simple architecture, more code to write, CISC = complex architecture, less code to write

Except EPIC. EPIC is complex code/complex architecture.

One could say the code size is Epic
Where does VLIW fit in?

this


see reddit.com/r/linux/comments/2ny1lz/im_greg_kroahhartman_linux_kernel_developer_ama/cmi8udx

You are so wrong it's not even funny.
The amount of pure assembly in Linux is minimal, ISAs won't affect LoC count.
What's important is the amount of features an architecture has and how to implement it. x86 has so much legacy shit you have to cope with everything at once, from jumping to protected mode and long mode, to assign legacy stuff like the GDT/LDT or the PIC. Not only these things are old as fuck, they are a complete nightmare to configure.
x86 is also an insane feature creep, it has so much shit accumulated over the years. For example it has at least 4 different types of hardware timers, each with a complete different configuration and interface. The interaction between the BIOS and how each component is configured is also insane. For example how the (maybe multiple!) IOAPICs are exposed, or the LAPIC default configuration of each core, and the documentation doesn't even make clear most of that shit, this is why most of the time Linux developers have to fix all the shit that BIOS developers break.
Seriously, grab an Intel system programming manual for once, it's out of this world.
ARM simplified a lot of this, I'm for certain the ARM code in Linux is way less bloated and much simpler, and it is RISC.

You seem to completely miss the point of why CISC will always be superior to RISC, in a lot of way CISC is like the Linux kernel itself, its timeless because its able to tack on instructions for pretty much everything which is why its still king in the high-end superconputing, industrial, and server spaces, just like Linux

No, you are missing the point that instruction sets have nothing to do with code bloat.
C code doesn't change, it is portable, RISC may bloat the binary size for the same code (Don't really know the answer), but it won't bloat the source code.
x86 binary size is still probably more bloated just because x86 has more features that have nothing to do with the instruction set.

That's not even true. And amd64 isnt pure CISC.
You'll see with POWER9.

Wrong, optimizing compilers will try and put large amounts of high-level code into specific x86 instructions, whereas RISC binaries are larger because they need to be compiled into many more instructions, RISC only simplifies the architecture itself, it does not favor binary size or execution speed

Its very much effectively CISC ARM Cortex-As aren't entirely RISC anymore either

The transistor space saved allows bigger caches and more complex pipelines.
It's a JIT CISC->RISC; the hardware itself is RISC.

Fug

->

You forgot most modern CPU are RISC on the inside. They have specialized chips to translate from CISC to their RISC just so they can be still backwards compatible.

It's proprietary software what's holding back hardware. We could have as many architectures as we wanted if it was easy to recompile the code.