Hacker News Reader

Comment by waddlesplash | Hacker News Reader

The OSDev wiki can probably teach you anything you need to know about "OS theory" (and practice, mostly on x86): https://wiki.osdev.org/Expanded_Main_Page

Depending on your style of programming, I'd recommend maybe not working on Linux if you are trying to learn kernel development and OS internals.

Have you looked at Haiku (https://www.haiku-os.org/)? We have a very well organized and commented modular-monolitic kernel, and a pretty active development team with a wide range of experience levels. I'm more than happy to help you (or anyone else) learn OS development!

Some example Haiku kernel code:

* "load_image_internal()", which is responsible for creating processes: https://github.com/haiku/haiku/blob/master/src/system/kernel...

* a recent change by me to replace a global lock with two local ones: https://github.com/haiku/haiku/commit/37eda488be1c9fee242e8e...

View on HN

> I'd recommend maybe not working on Linux if you are trying to learn kernel development and OS internals.

Could you also tell why ?

The Linux kernel is really, really large, and changes extremely rapidly, to the point of breaking such "experiments" (as the original poster already noted.) It's also rather loosely commented and, aside from a handful of core systems, not so well documented.

The BSDs do much better here; they have excellent manpages for almost all kernel APIs, manuals for how the internals work, and very good source code commenting and organization practices. Haiku is not as good as the BSDs on manpages and manuals, but that's the only real way we differ from them (in this respect.)

Complexity.

Start with something where you can substantially wrap your head around the whole thing, like XV6 or Minix, and it's vastly easier to look at chucks of something like Linux and see "oh, this fits into the mental picture here". For me, in the mists of the old days, learning Unix V6 out of the Lyons books (very slim volumes of annotation...wonderful stuff) make it easy to understand what was going on in V7, which made 4.2BSD and progeny accessible, which made SVR[234] somewhat weird and different, but still conceptually understandable, which made most everything Unix-ish afterword (including Linux) something you still had the vernacular to understand.

Now...to be fair...this leaves out a lot of really valuable OS knowledge. There's no IBM large system OS (e.g VM/370->z/OS, VM/CMS, TPF). No Seven Dwarfs OS (DEC VMS, Burroughs B-series, DG Nova, CDC NOS, etc.). Nothing for the really interesting Lisp or Smalltalk machines, the Perq or the Mesa/Cedar workstations. No interesting small systems OS: OS/2, classic MacOS, OS-9, much less the Windows NT family. Much less any of the embedded/RTOS world.

But you can still learn alot.

I have heard of Haiku,but haven't looked at it in a while. However, I have heard great things about it and would certainly be interesting in learning and contributing

I and most of the other developers hang out on Freenode#haiku, and of course on our mailing lists. Come say hello and get involved, indeed. More than happy to teach :)

I really love to see this kind of stuff within the community. I'd really love to take you up on this offer sometime :)

Hey, please do! Onboarding new people and teaching skills is fun, and learning them while working on a project people actually use for day-to-day work is even more fun.

I idle in #haiku on Freenode, so ping me there and I'll usually reply soon enough. :)

> modular-monolitic kernel

This sounds like a bit of an oxymoron. What is a modular-monolithic kernel?

The Linux kernel, as well as the FreeBSD kernel, supports the loading and unloading of kernel modules, which are compiled binaries that can be linked to the kernel while it is running. These modules are still in the address space of the kernel; the term "monolithic" refers to the fact that all portions of the kernel, even kernel modules, are running in the same address space. This is different from a microkernel like Mach where various operating system subsystems such as networking and the file system are running as separate user-level processes (thus having their own address spaces).

"Monolithic" refers more to the way drivers and the kernel interact, i.e. if drivers live in the kernel address space, can read/write all kernel memory, call functions in other drivers, etc., then it's a monolithic kernel. If instead each driver is its own process with address space, and calls into the kernel via syscalls like any other process, then it is a microkernel.

"Modular" refers to linkage and overall design. The Linux kernel is mostly "statically" linked (there is DKMS but it isn't so widely used) with most major systems in the "kernel" itself, and something similar is true in the FreeBSD world.

Haiku, on the other hand, has a rather small (2.2MB binary on i386) kernel with no drivers built in at all (not even PCI); and loads all its drivers as relocateable shared-objects. This means unloading and reloading kernel modules at runtime (or boot) is very easy; so as long as you don't crash or hang the system, you can keep reloading drivers as much as you like without rebooting.

I know macOS also uses dynamic kernel modules, but I'm not as familiar with that system.

Function with 9 arguments, 200 lines. Mix of abstraction levels. Basically untestable. Could use RAII.

> Function with 9 arguments

That's nothing, let me show you some of the ones in the VM...

> Mix of abstraction levels

What are you referring to here?

> Basically untestable.

Unit-testable, no. Integration-testable, absolutely; POSIX testsuites are not so hard to write. And this function is called (tens of) thousands of times per hour while you are using the OS, remember.

> Could use RAII.

It is already using RAII reference and lock objects, what improvement do you think could be had here? There are no exceptions in the kernel, so that's not a concern.

If this is your criticism of Haiku's kernel code ... go take a look at some of the equivalents in the BSDs or Linux, then. We are by far and away better than those by your metrics (especially as, you know, those are C and this is C++.)

But do these specific metrics matter? Probably not. "9 arguments" is not a mark against a function in all cases, neither is length or abstraction mixing. Those can and usually are bad, but kernels are a different ballgame altogether.

Reply on news.ycombinator.com