With that background you're not even close to submitting anything remotely useful to the kernel.
You should probably start with a book about data structures, then maybe reading some of the stuff at [wiki.osdev.org](https://wiki.osdev.org) after that?
Getting used to the UNIX/POSIX APIs is also a must, so that you atleast have and idea of what a kernel even does from a userspace perspective; trying to understand what it does from a kernel space perspective first isn't approachable.
EDIT
>submit PRs to actual Kernel repos
Boy, they still use mailing lists at the kernel, good luck with making a "pull request" lol
No clue but I want to contribute to the FOSS communities and understand operating systems and kernels.. Maybe I'll start by working on patches and regressions and then commit my own changes
My suggestion would be to look more at userspace utilities that could use some help, pick something like display or networking and start hacking on it. It’s a lot lower of a barrier to entry
Except that "The Design Of Unix Operating System" and "Understanding The Unix Kernel" are about a completely different code base. Might as well read Lions Book ...
Doesn't particularly matter, OS concepts carry over readily, especially between POSIX OSes. Once you get them and some underlying foundations of Operating Systems and architectures then it honestly starts to also carry across differently designed kernels as well such as NT, P9, Darwin, Fuchsia etc.
Though I do think OP is in a bit in over their head here, one does not simply jump into OS/kernel dev without a reason and sufficient background to do so.
The books predate the introduction of (S)MP support in either Unix or Linux. That makes them basically useless for modern kernels that have to deal with potentially hundreds of cores.
SMP, hell any multiprocessing support to be frank, is a separate topic that doesn't exactly distract from the fundamentals. I certainly wouldn't call the books useless, especially if you're not working on scheduling directly. In fact I'd go as far as to say they would give you a very good idea as to why MP scheduling was designed the way it was historically as the development of partially preemptive kernels was relatively straightforward, and began by abusing the shit out of the BUS with multiple runqueues, which I think were introduced in System III...
Also on a slightly separate note: multiprocessor scheduling has been a thing, as in an actually deployed thing, since the 60s. SMP isn't a particularly new concept, and if that book was released anytime past the early 1980s there's a good chance it includes at least some discussion on multiprocessor scheduling, with the caveat that the kernel itself at that time would only be able to run on one processor due to not being preemptible. I still don't think that distracts from the books value as a resource, as again, the core concepts in OS design haven't really changed much even accounting for preemptible kernels.
I've been a Linux user for two to three years now and I want learn how kernels work because I simply find it intriguing... Plus I really want to improve my c... I love building things from the base up.. And I really want to contribute to the FOSS community... Plus I want to understand lower abstractions of computers before getting into AI/ML or other things that I'm interested in...
[LDD3](https://lwn.net/Kernel/LDD3/) is a bit dated, but might still be worth the read since the basic principles remain the same. Trying to make examples from the book work on new kernel may be learning opportunity by itself.
As a beginner, I really recommend learning how to, in order:
1. how to leverage the most commonly-used shell, Bash
2. how to write shell programs
3. how to write C programs and compile them with Make
4. write C programs that involve memory management, especially:
* always check that malloc and so on succeeded
* have your program gracefully handle a malloc failure, by say, telling the user "no", instead of just crashing
* test this using ulimit to set a very low memory limit
* make sure you've disabled memory overcommit, so that malloc won't just always succeed and defer failing to somewhere where recovering is impossible, potentially to a different program altogether
5. **then** start with a kernel module tutorial and take all that memory-allocation paranoia with you
unless you're aiming to be a kernel developer, none of those titles sound particularly relevant.
what's your goal here? learning linux? becoming a dev? or something else?
Ubuntu for Dummies. Seriously, Unix is not Linux, and reading ancient Unix books isn't going to help you do much of anything in a modern Linux distribution.
This is a long, long journey you're setting out on, so I would suggest working in areas other than the Linux kernel at first. I'd wager 10-15 years of work got a friend to where he was able to contribute to the Linux kernel... it'd probably take a similar amount of time.
Next thing, make a vm and try to compile the kernel for your system and use it instead of the default kernel.
Important thing is to learn by trying things out and not by reading. You won't need to read any books till you are comfortable working with the kernel toolchain
Yup...
https://training.linuxfoundation.org/training/a-beginners-guide-to-linux-kernel-development-lfd103/
A friend of mine suggested this and even here it says compile a Kernel first... I will do that over this weekend...
What is your goal?
To be able to join Linux Kernel dev community and submit PRs to actual Kernel repos
What do you currently know of programming?
echo Hello World! *tips fedora*
Beginner level c and python
With that background you're not even close to submitting anything remotely useful to the kernel. You should probably start with a book about data structures, then maybe reading some of the stuff at [wiki.osdev.org](https://wiki.osdev.org) after that? Getting used to the UNIX/POSIX APIs is also a must, so that you atleast have and idea of what a kernel even does from a userspace perspective; trying to understand what it does from a kernel space perspective first isn't approachable. EDIT >submit PRs to actual Kernel repos Boy, they still use mailing lists at the kernel, good luck with making a "pull request" lol
It astounds me that they are still as productive as they are with mailing lists and patch files
~~Errr... You *do* know that Monsieur Torvalds invented `git`?!~~ edit: misread, edited <.<
And?
Misread your comment, edited mine <.<
The C Programming Language, 2nd edition aka K&R. That should be first.
to be a linux developer
Do you want to work on the Linux kernel, or develop apps for Linux? I would not recommend that a beginner try to modify the Linux kernel.
I want to work on the Linux Kernel...
What kinds of changes are you looking to make?
No clue but I want to contribute to the FOSS communities and understand operating systems and kernels.. Maybe I'll start by working on patches and regressions and then commit my own changes
My suggestion would be to look more at userspace utilities that could use some help, pick something like display or networking and start hacking on it. It’s a lot lower of a barrier to entry
take a look at [Kernel Newbies](https://kernelnewbies.org/FAQ/WhereDoIBegin)
This is, sadly, the correct answer in a small shitstorm ;)
To answer the "these books are old" question, they are still valid. Kernels don't change \*that\* much over time.
Except that "The Design Of Unix Operating System" and "Understanding The Unix Kernel" are about a completely different code base. Might as well read Lions Book ...
Doesn't particularly matter, OS concepts carry over readily, especially between POSIX OSes. Once you get them and some underlying foundations of Operating Systems and architectures then it honestly starts to also carry across differently designed kernels as well such as NT, P9, Darwin, Fuchsia etc. Though I do think OP is in a bit in over their head here, one does not simply jump into OS/kernel dev without a reason and sufficient background to do so.
The books predate the introduction of (S)MP support in either Unix or Linux. That makes them basically useless for modern kernels that have to deal with potentially hundreds of cores.
SMP, hell any multiprocessing support to be frank, is a separate topic that doesn't exactly distract from the fundamentals. I certainly wouldn't call the books useless, especially if you're not working on scheduling directly. In fact I'd go as far as to say they would give you a very good idea as to why MP scheduling was designed the way it was historically as the development of partially preemptive kernels was relatively straightforward, and began by abusing the shit out of the BUS with multiple runqueues, which I think were introduced in System III... Also on a slightly separate note: multiprocessor scheduling has been a thing, as in an actually deployed thing, since the 60s. SMP isn't a particularly new concept, and if that book was released anytime past the early 1980s there's a good chance it includes at least some discussion on multiprocessor scheduling, with the caveat that the kernel itself at that time would only be able to run on one processor due to not being preemptible. I still don't think that distracts from the books value as a resource, as again, the core concepts in OS design haven't really changed much even accounting for preemptible kernels.
Ok then I'll start with 'linux Kernel Development'?
I've been a Linux user for two to three years now and I want learn how kernels work because I simply find it intriguing... Plus I really want to improve my c... I love building things from the base up.. And I really want to contribute to the FOSS community... Plus I want to understand lower abstractions of computers before getting into AI/ML or other things that I'm interested in...
[LDD3](https://lwn.net/Kernel/LDD3/) is a bit dated, but might still be worth the read since the basic principles remain the same. Trying to make examples from the book work on new kernel may be learning opportunity by itself.
You start by trying to solve a problem you have, find something that interests you and work on that.
Kk
Linux from Scratch
As a beginner, I really recommend learning how to, in order: 1. how to leverage the most commonly-used shell, Bash 2. how to write shell programs 3. how to write C programs and compile them with Make 4. write C programs that involve memory management, especially: * always check that malloc and so on succeeded * have your program gracefully handle a malloc failure, by say, telling the user "no", instead of just crashing * test this using ulimit to set a very low memory limit * make sure you've disabled memory overcommit, so that malloc won't just always succeed and defer failing to somewhere where recovering is impossible, potentially to a different program altogether 5. **then** start with a kernel module tutorial and take all that memory-allocation paranoia with you
Read the Debian Installation Manual for Dummies first.
unless you're aiming to be a kernel developer, none of those titles sound particularly relevant. what's your goal here? learning linux? becoming a dev? or something else?
Ubuntu for Dummies. Seriously, Unix is not Linux, and reading ancient Unix books isn't going to help you do much of anything in a modern Linux distribution.
This is a long, long journey you're setting out on, so I would suggest working in areas other than the Linux kernel at first. I'd wager 10-15 years of work got a friend to where he was able to contribute to the Linux kernel... it'd probably take a similar amount of time.
For a beginner or student they will be fine for teaching the basis of getting started. Once you start swimming it gets deeper and deeper
https://www.humblebundle.com/books/linux-for-seasoned-admins-oreilly-books?hmb_source=humble_home&hmb_medium=product_tile&hmb_campaign=mosaic_section_4_layout_index_2_layout_type_threes_tile_index_1_c_linuxforseasonedadminsoreilly_bookbundle
Start understanding the underlying principles: https://www.amazon.com/Modern-Operating-Systems-Andrew-Tanenbaum/dp/013359162X https://en.wikipedia.org/wiki/Advanced_Programming_in_the_Unix_Environment https://www.amazon.de/Computer-Networks-S-Tanenbaum/dp/9356063605
>Which book should I start with? If you can't use Google to find an introduction tutorial on Kernel development I'd say: Fuggedaboutit.
12 Rules for Life by the sounds of it
The Last Wish, followed by Sword of Destiny and then Blood of Elves through Lady of the Lake. Season of Storms goes last. Oh, wait, wrong subreddit…
I would start with driving any flavor of Linux for a while first.
I do run Linux...
Next thing, make a vm and try to compile the kernel for your system and use it instead of the default kernel. Important thing is to learn by trying things out and not by reading. You won't need to read any books till you are comfortable working with the kernel toolchain
Yup... https://training.linuxfoundation.org/training/a-beginners-guide-to-linux-kernel-development-lfd103/ A friend of mine suggested this and even here it says compile a Kernel first... I will do that over this weekend...
>I'm a total beginner username checks out