Comment by Alupis | Hacker News Reader

Comment by Alupis | Hacker News Reader

Parent Full thread

I would highly recommend starting out by building your own linux distro by following the linux-from-scratch book or similar.[1]

You will learn a lot about what goes into making a distro actually boot, how the different pieces of software are interacting with each other, and how to solve and debug typical issues and kernel panics.

From there, I think many would recommend attempting to make some sort of Kernel Module, even if it's a very basic one that isn't of much use. The experience alone will teach you a lot of valuable skills and knowledge.[2]

Learning some assembler will help as well. There is a great free ebook from the gnu assembler (GAS) project [3]. Assembler will help teach you how the computer is really doing what it does. This is important if you are going to be working closer to the kernel and most of the critical subsystems, be in Linux or the BSD's (even Windows actually). There are many different Assembler languages, but learning some basics in one will help you understand how others work.

[1] http://www.linuxfromscratch.org/lfs/

[2] http://www.linuxchix.org/content/courses/kernel_hacking/less...

[3] http://download.savannah.gnu.org/releases/pgubook/Programmin...

I think this answer is pretty bad. You don't need to do all that CJ stuff of building a Linux just to learn systems programming. That's all domain-specific knowledge that would be irrelevant to the vast majority of people doing systems programming on Linux, and all of the people doing systems programming on other operating systems.

Assembler is also a low priority to learn. The details of x86 assembly are not important until you happen to need them for some reason -- in which case, learn it when you need it. The same goes for Linux and OS details. Most systems programming does not require the use of assembly language. If you do want to get a feel for "what assembly is", do some of the challenges at https://microcorruption.com/ . It's a lot of fun in its own right and avoids x86 minutia, and you'll get a good picture of how what a stack would look like and what function calling can look like.

What you need to do to learn "systems programming" is crack open C and C++ and get yourself pretty good at them. And get good at dealing with multithreading and the like. That's what the original poster is asking for.

I think it's worth spending a while with user-level C (maybe complete 1 or 2 nontrivial projects) before attempting to write kernel modules.

Ok, what would you consider a nontrivial project?

My first C class had Gameboy programming. There were no libraries to include, and most of the data manipulation was around scores and drawing pixels.

My second C class went into mutexes and things (producers & consumers of some data)

My third class that used C had kernel modules. Our kernel module project was to write a model of a parking lot. There was some user code that called our module saying whether it was a normal vehicle, a handicap vehicle, or an emergency vehicle. The parking lot also had 2 states, emergency or normal. In an emergency, only emergency vehicles could come in, everything else was rejected. The code ran with M floors and N parking spaces per floor, and returned the lowest floor in which you could park.

We also wrote an identical piece of userspace code, and compared how fast each performed.

My C education followed the exact same pattern (Georgia Tech). I'm really happy with it. The whole progression felt very organic.

He may possibly be referring to just getting familiar with C, since there is a lot of stuff you must worry about with C that you may not be used to with higher level languages (such as having to manually manage your memory allocates, etc).

I interpret gchp as asking for suggestions as to projects of the appropriate scope.

This is great, thank you! LFS looks good.

Reply on news.ycombinator.com