
Interactive map of Linux kernel - mayankkaizen
http://www.makelinux.net/kernel_map/
======
fauria
Link to PNG image:
[http://www.makelinux.net/kernel_map/LKM3_2048.png](http://www.makelinux.net/kernel_map/LKM3_2048.png)

------
Someone1234
That's a fun map.

The Linux kernel has more device drivers embedded in the core than I
anticipated. I'm guessing most are used for bootstrapping/fallback (e.g.
loading the "actual" drivers)? Such as ext4, ipw2100, ac97, i8042, etc.

Just to be clear, I'd imagine most of the above are common enough to have on
almost all but the most niche Linux distributions. My question relates around
having them this high up in the source tree, rather than why they're
useful/what they do.

~~~
angelsl
What do you mean "embedded in the core"?

All drivers are in-tree.

~~~
exikyut
Technically unmodularizable

Architecturally integrated into everyone's "this is part of the kernel and not
a random printer driver" mental model

------
fouc
Feels like this needs to be a 3D map. 2 dimensions isn't quite cutting it.

~~~
oneweekwonder
Something like jscity[0].

[0]: [https://github.com/ASERG-
UFMG/JSCity/wiki/JSCITY](https://github.com/ASERG-UFMG/JSCity/wiki/JSCITY)

------
snvzz
Linux is such a mess that it needs a map.

It's no surprise they're paying massive technical debt over it. Work that
would take a few hours in a well-structured system does take months on Linux.

Isn't surprising either that Dragonfly BSD's outperforming Linux in network
throughput, despite its small number of developers.

They went for a components as concurrent lockless system servers approach [1]
instead of a complex mess of fine-grained locks like Linux (and FreeBSD,
following them) did.

[1]
[https://www.dragonflybsd.org/presentations/](https://www.dragonflybsd.org/presentations/)

~~~
jimmy1
I can only imagine what sort of chaos exists in Windows and OSX. Unfortunately
I can only do that: imagine, because it is closed source. With Linux, I can at
least see the mess, and well, make a map out of it.

~~~
AnIdiotOnTheNet
I find it annoying that any time someone criticises Linux for something
someone has to come and point out that Windows and OSX are also kinda crappy.
It's true enough, it's also just useless defensiveness. Maybe the bar we set
for ourselves should be a little higher than the stuff everyone complains
about?

~~~
andrepd
Maybe it's just nigh impossible to build such a complex engineering project
and keep it elegant through 25 years of development?

------
std0147
I love Linux!

this map is very useful

------
inetknght
> _Please Enable JavaScript or use plain html_

Link then goes 404.

------
simooooo
As a noob observing..Many of them seem to have names nothing like what their
actual purpose is

~~~
LeonM
A dead comment by user 'simoooo':

> As a noob observing..Many of them seem to have names nothing like what their
> actual purpose is

Having worked a bit with low level kernel stuff (porting a unix OS to a new
platform), I understand his observation. Even after working with the kernel
for a while, many names don't really make sense.

Mandatory quote of Phil Karlton:

> There are only two hard things in Computer Science: cache invalidation and
> naming things.

~~~
nikomen
Out of curiosity, do you know of any examples of seemingly misnamed objects in
the kernel?

~~~
roblabla
My recent venture in the filesystem have been somewhat fun. The problem isn't
so much misnamed objects, and more that the kernel is filled with seemingly
undocumented, arcane, old things. `sb_bread` isn't some kind of food, but the
"SuperBlock Buffer Read" method, and `brelse` means "Buffer Release" (and not,
somethingsomething else, as I initially thought).

BH means Buffer Head. The meaning and usage of Buffer Head has changed a lot
across Linux versions. It's the basic unit of IO operations, but nowadays most
users would use a bio for most of what you would have used a buffer head in
the past. When you're working on filesystems you'll have to use BHs to talk to
the hard drive though.

Linux FS infrastructure and Ext2 share a lot of names. For instance, ext2 and
linux both have superblocks, inodes, blocks, etc. They are... logically the
same, but at the same time they're very different - one lives purely on the
disk, the other provides functions to the kernel. This makes conversation very
complicated, when talking about the superblock, you have to mention _which_
superblock you're talking about, because that's not always obvious from
context.

~~~
slrz
Names like brelse, bread, namei and so on have a _long_ history in Unix
kernels and file systems. That history forms people's expectations. If you
provide a namei operation in your code, you better call it namei and not make
up some other, ostensibly more clear, identifier for it.

------
RickJWagner
Ah, cool!

Hacker News paydirt.

