Every update I clone the current boot environment, execute it as a jail, run upgrades in there, and then once upgrades finish I set it to "boot just once", all using the built in bectl. At no point during an upgrade is the running OS in an inconsistent state. Powerloss during upgrade? no problem, since it wasn't activated yet your server comes up with the previous version. And you can either junk the partial upgraded env and start over, or jail it again and continue.
I only wish laptop support was a bit better. But since my laptop is more of a pet, at least it can have Void.
Awesome work!
I await the Linux version :)
if people dont get too 'anti' about it, it might grown into a good book at some point over editions.
It would certainly be useful to have such a book be complete and maintained (tons of work ofc).
personally id prefer a book that requires abit more prework, like learning C etc. and Unix, so it can be more compact specific to device drivers. 4k+ pages is a lot to chew through and more a thing for reference manuals like intel/amd/acpi manuals etc. (lot of tables and diagrams etc.)
If something in a translated edition seems unclear, inconsistent, or technically questionable, please refer to the English version as the source of truth. Help with reviewing and improving the translations is very welcome (see Contributing below)."
---
This doesn't directly answer your question though.
> Do I need to know C before starting?
> No. Chapters 4 and 5 teach C from the ground up, focusing on the parts of the language that matter for kernel work (pointers, structures, memory layout, the preprocessor, and calling conventions). If you already know C well, sidebars in those chapters tell you what to skim and what to read carefully.
> Do I need to know UNIX or FreeBSD?
> No. Chapter 2 walks you through installing FreeBSD in a VM or on bare metal, and Chapter 3 introduces the UNIX command line, filesystem, processes, permissions, and editors. By the end of Part 1 you will have a working lab and the vocabulary to use it.
If you're trying to get more contributors to your project, that seems like an excellent way to do it:) You have any interest in working on the project? Great, here's everything to get you there!
I used to point at LFS/BLFS in the past (Linux from scratch), since the idea is great. Unfortunately they are now systemd-only, which kind of defeats some of the points, IMO. But documentation is useful, so FreeBSD improving here is good. Perhaps one day it can compete against Linux again. :D
I would rather the author automate the mundane and focus on conveying their ideas clearly.
As an aside, is there a Linux version for this ?
So I would expect that they would thoroughly check the book for inaccuracies, errors and issues before releasing it after proof-reading, otherwise it would say a lot about how they use LLMs and not checking over it would hurt their own reputation.
Could you be more specific? Maybe open an issue listing points for possible improvement?
a) it's a good introduction to C
b) a human read any of it
https://github.com/ebrandi/FDD-book/blob/main/content/chapte...
This book is a dishonest AI scam.
Look at this totally useless """introduction""" to C: https://github.com/ebrandi/FDD-book/blob/main/content/chapte...
First of all this is an entire book, it's 76,000 words. But look at the first nontrivial example of C after "hello world," under "Bonus learning point about C return values"
exec_map_first_page(struct image_params *imgp)
{
vm_object_t object;
vm_page_t m;
int error;
if (imgp->firstpage != NULL)
exec_unmap_first_page(imgp);
object = imgp->vp->v_object;
if (object == NULL)
return (EACCES);
#if VM_NRESERVLEVEL > 0
if ((object->flags & OBJ_COLORED) == 0) {
VM_OBJECT_WLOCK(object);
vm_object_color(object, 0);
VM_OBJECT_WUNLOCK(object);
}
#endif
error = vm_page_grab_valid_unlocked(&m, object, 0,
VM_ALLOC_COUNT(VM_INITIAL_PAGEIN) |
VM_ALLOC_NORMAL | VM_ALLOC_NOBUSY | VM_ALLOC_WIRED);
if (error != VM_PAGER_OK)
return (EIO);
imgp->firstpage = sf_buf_alloc(m, 0);
imgp->image_header = (char *)sf_buf_kva(imgp->firstpage);
return (0);
}
This teaches nobody anything. I am sorry but this project is completely useless and there's no way Brandi read a single word of it. This entire book is a dishonest AI scam. I hate LLMs. It is hard to think of another computer technology that has done so much damage for so little good.Edit: I mean look at the intro to for loops. This is supposed to be for total beginners. Example 1:
for (int i = 0; i < 10; i++) {
printf("%d\n", i);
}
>> Start at i = 0>> Repeat while i < 10
>> Increment i each time by 1 (i++)
Example 2:
for (i = 0; n > 0 && i < IFLIB_MAX_RX_REFRESH; n--, i++) {
struct netmap_slot *slot = &ring->slot[nm_i];
uint64_t paddr;
void *addr = PNMB(na, slot, &paddr);
/\* ... work per buffer ... \*/
nm_i = nm_next(nm_i, lim);
nic_i = nm_next(nic_i, lim);
}
>> What this loop does>> * The driver is refilling receive buffers so the NIC can keep receiving packets.
>> * It processes buffers in batches: up to IFLIB_MAX_RX_REFRESH each time.
>> * i counts how many buffers we've handled in this batch. n is the total remaining buffers to refill; it decrements every iteration.
>> * For each buffer, the code grabs its slot, figures out the physical address, readies it for DMA, then advances the ring indices (nm_i, nic_i).
>> * The loop stops when either the batch is full (i hits the max) or there's nothing left to do (n == 0). The batch is then "published" to the NIC by the code right after the loop.
>> In essence, a for loop is the go-to choice when you have a clear limit on how many times something should run. It packages initialisation, condition checking, and iteration updates into a single, compact header, making the flow easy to follow.
Total garbage. This has literally zero educational value. I assume Brandi is just trying to make a quick buck, he truly has not even glanced at the output. He should be ashamed of himself.
From First Steps to Kernel Mastery
by Edson Brandi Β· Version 2.0 (April 2026)
FreeBSD Device Drivers: From First Steps to Kernel Mastery is a free, open-source book that takes you from "I've never written kernel code" to "I can write, debug, and submit production-quality FreeBSD drivers." It is a guided course rather than a reference, structured around 38 chapters, 6 appendices, and dozens of hands-on labs that compile and load on a real FreeBSD 14.x system.
The book is aimed at readers who are willing to learn rather than are already qualified. It begins with UNIX fundamentals and the C language, walks step by step through every concept the kernel will demand of you, and only then opens the door to driver development. By the time you reach DMA, interrupts, and PCI work, the vocabulary feels earned, not imposed.
"Kernel programming is still programming, only with more explicit rules, greater responsibility, and a bit more power. Once you understand that, the fear gives way to excitement." (from Chapter 1)
There are excellent FreeBSD kernel references already, including man 9, the Architecture Handbook, and the Newbus papers. What has been missing is a single text that:
myfirst driver evolves chapter by chapter, gaining synchronisation, then hardware access, then interrupts, then DMA. You see the same code mature in your own hands.The book is organised into seven parts that build on each other:
| Part | Title | Focus |
|---|---|---|
| 1 | Foundations: FreeBSD, C, and the Kernel | Lab setup, UNIX, C for kernel work, driver anatomy |
| 2 | Building Your First Driver | Character drivers, device files, read/write, I/O |
| 3 | Concurrency and Synchronization | Threads, mutexes, condvars, timers, taskqueues, semaphores |
| 4 | Hardware and Platform-Level Integration | PCI, interrupts, MSI/MSI-X, DMA, power management |
| 5 | Debugging, Tools, and Real-World Practices | Tracing, KGDB, advanced debugging, performance tuning |
| 6 | Writing Transport-Specific Drivers | USB, serial, storage/VFS, network drivers |
| 7 | Mastery Topics: Special Scenarios and Edge Cases | Portability, virtualisation, security, embedded, reverse engineering, upstream submission |
By the end, you will have written and loaded your own kernel modules, built a character driver, handled real interrupts and DMA, debugged kernel panics, profiled your driver under load, and walked through every step of contributing your work back to the FreeBSD Project.
| Pages | 4,500+ |
| Chapters | 38 |
| Appendices | 6 |
| Reading time | ~100 hours |
| Lab time | ~100 hours |
| Total study time | ~200 hours (β6 months at 5 hrs/week) |
| Target FreeBSD release | 14.3 |
| Languages | English (original) Β· Brazilian Portuguese (AI-translated) Β· Spanish (AI-translated) |
| Formats | PDF Β· EPUB Β· HTML Β· Markdown source |
The recommended pace is one chapter per week at roughly five hours of weekly study. That schedule puts the whole book within reach across an academic year. Some chapters (especially Chapter 4 on C, and the Part 4 hardware chapters) naturally span multiple weeks.
The labs are strongly recommended. Kernel programming rewards muscle memory in a way few disciplines do. The same attach pattern, the same cleanup chain, and the same locking shape appear chapter after chapter and driver after driver. Typing those patterns, compiling them, loading them into a running kernel, and watching them fail on purpose is the single most effective way to internalise them.
If you already know C, UNIX, and the general shape of an OS kernel, fast-path notes throughout Part 1 tell you which sections to read carefully and which you can skim.
Version 2.0 is available now on the Releases page in three languages and three formats:
| Language | EPUB | HTML | |
|---|---|---|---|
| English (original) | EPUB | HTML | |
| PortuguΓͺs (Brasil), AI-translated | EPUB | HTML | |
| EspaΓ±ol, AI-translated | EPUB | HTML |
You can also browse the Markdown source directly in the content/ directory, or build the book yourself with scripts/build-book.sh.
The English version is the original and authoritative version of the book. The Brazilian Portuguese and Spanish editions were translated using AI and have not yet undergone a full human technical review. They are published to make the material accessible to more readers, but they may contain translation mistakes, awkward wording, or technical inaccuracies introduced during translation.
If something in a translated edition seems unclear, inconsistent, or technically questionable, please refer to the English version as the source of truth. Help with reviewing and improving the translations is very welcome (see Contributing below).
This is a draft release of a very large book. A few things to be aware of:
content/ for a clean version.FDD-book/
βββ content/ # Book content (Markdown)
β βββ chapters/ # Chapters by Part
β βββ appendices/ # Appendices A-F
βββ examples/ # Source code from the book
βββ translations/
β βββ pt_BR/ # Brazilian Portuguese (AI-translated)
β βββ es_ES/ # Spanish (AI-translated)
βββ scripts/ # Build and utility scripts
Contributions of every kind are welcome, including corrections, clarifications, new examples, translations, and reviews from FreeBSD developers and learners alike.
When filing an issue, please include:
en_US, pt_BR, es_ES)git checkout -b feature/your-changescripts/build-book.shgit commit -m "Chapter 18: clarify BAR mapping"When you're stuck while reading the book, filing an issue helps. If a passage seems wrong or a lab fails unexpectedly, every report makes the next reader's path smoother.
The honest answer is that the FreeBSD Project needs new contributors, and the path into kernel and driver work has always been steeper than it should be. Most existing material assumes you already know UNIX, already know C well, already know what a bus is, and already know how to read a kernel source tree. That works for the people who are already most of the way there. It does very little for the curious developer who wants to start.
The goal of this book is to lower that on-ramp. If even a small number of readers finish it and go on to submit patches, review code, write new drivers, or eventually become FreeBSD committers, the book has done its job. Training the next generation of FreeBSD contributors is the reason this work was written.
No. Chapters 4 and 5 teach C from the ground up, focusing on the parts of the language that matter for kernel work (pointers, structures, memory layout, the preprocessor, and calling conventions). If you already know C well, sidebars in those chapters tell you what to skim and what to read carefully.
No. Chapter 2 walks you through installing FreeBSD in a VM or on bare metal, and Chapter 3 introduces the UNIX command line, filesystem, processes, permissions, and editors. By the end of Part 1 you will have a working lab and the vocabulary to use it.
For most of the book, no. A virtual machine running FreeBSD 14.x is enough for the foundations, the first driver chapters, concurrency and synchronization, and a large portion of the debugging material. Real hardware becomes useful (but is still not strictly required) when you reach the PCI, interrupt, and DMA chapters in Part 4. Those chapters are written so that the concepts make sense even if you only run them in a VM.
Indirectly, yes. The kernel programming discipline transfers very well: locking strategy, memory management, interrupt context, DMA mapping, the difference between sleeping and non-sleeping code paths, defensive cleanup ordering. The specific APIs differ. After reading this book you will not know the Linux device model, but you will recognise its problems and the shape of its solutions, and you will be able to read Linux Device Drivers (LDD) much more easily.
Every API, every example, and every lab was planned to be executed under FreeBSD 14.3 source tree and the corresponding man 9 pages. Targeting a specific release lets the book be precise about function signatures, header locations, and behaviour. The concepts will outlive 14.x by many years; the exact line numbers and small API details will not, and the book is honest about that.
No. This is an independent educational book about FreeBSD device driver development. It is not an official publication of the FreeBSD Project. The author is a FreeBSD committer and a member of the Documentation Engineering Team (DocEng), but the book reflects his work and views, not an official Project position.
If you read carefully and do the labs, plan for around 200 hours of total work. That is roughly 100 hours of reading and 100 hours of hands-on lab time. At five hours a week that is about a six-month evening project; at ten hours a week, a focused two-month sprint. Reading without doing the labs cuts the time roughly in half but also cuts the value: kernel programming rewards muscle memory in a way few disciplines do.
You can, but you probably shouldn't. The labs are where prose becomes reflex. Patterns like attach ordering, cleanup unwinding, and lock acquisition shape recur in every chapter, and the only reliable way to internalise them is to type them, compile them, load them into a running kernel, and watch them fail on purpose. Readers who skip the labs report progress that feels smooth at first and then quietly stalls around Part 3 or Part 4.
Chapter 37 covers the full submission workflow: how to prepare a patch, how to use Phabricator (the FreeBSD code review system), how to find a committer to sponsor your work, how to respond to review feedback, and how to shepherd a driver into the tree. The earlier chapters build the technical skill; Chapter 37 builds the social workflow. Both matter.
Start at Chapter 1 unless you have a reason not to. The book is cumulative; later chapters lean on vocabulary and habits established earlier. If you already know C, UNIX, and the general shape of an OS kernel, the fast-path notes inside Part 1 tell you what to skim. If a specific subsystem is what brought you here (USB, networking, storage, PCI), it is fine to read Parts 1 and 2 carefully and then jump ahead, but expect to circle back when terms from earlier chapters reappear.
Open an issue on GitHub. Include the language version, the format you were reading, the chapter or section, a short description of the problem, and a suggested correction if you have one. Every report makes the next reader's experience better. Translation issues in the pt_BR and es_ES editions are especially welcome, since those have not yet had a full human technical review.
Yes. It is released under the MIT License. You can read it, share it, print it, quote it, build on it, and translate it. Attribution is appreciated but not required for personal use. If you want to support the work, the most useful things you can do are: tell other people about the book, file issues when you find problems, contribute reviews or translations, and (if it eventually leads you there) submit your own work to the FreeBSD Project.
I'm Edson Brandi. My path into technology was anything but conventional. I started as a chemistry student at Unicamp in Brazil in 1995, with no plan to work with computers, but with one persistent question: how does this actually work? That question led me to FreeBSD, and FreeBSD has shaped my career ever since.
In the years that followed I founded the Brazilian FreeBSD User Group (FUG-BR), co-created the FreeBSD LiveCD Tool Set, and in 2002 co-founded FreeBSD Brasil, a company providing FreeBSD training, consulting, and support that still operates today. I'm a FreeBSD committer and currently a member of the FreeBSD Documentation Engineering Team (DocEng), helping maintain the systems that keep FreeBSD's documentation alive and accessible worldwide.
Professionally, I've spent my career in infrastructure and engineering leadership across multiple industries, and today I serve as IT Director at a fintech company in London.
I wrote this book because I want other curious people to have the on-ramp I never had. You don't need a computer science degree to write kernel code. What you need is curiosity, persistence, patience, and a guide that meets you where you are.
Edson Brandi Β· ebrandi@FreeBSD.org
This book and its accompanying source code are released under the MIT License. See LICENSE for the full text. You are free to read, share, and build on this work; attribution is appreciated.
If this book helps you, please star the repository and share it with someone else who's curious about how computers really work.
you yourself chose to spend time on something to your own frustration even though at that point you already knew it wasnt for you. frustrating yourself further trying to find examples to help frustrate others too.
look at how you are behaving and then realise you are saying someone else should be ashamed of themselves.
If you disagree with the book a simple excerpt and note would suffice. if it's 'super clearly bad' it does not need to contain a load of emotions to transmit that message.
The scam is not stating up front "this was written by an LLM and I haven't read it." The dishonesty is claiming this book will teach you such-and-such when the author actually has no idea. It really is a scam. Even if he's not making anything directly, he's already earned 150 stars in the GitHub pseudoeconomy, plus good word-of-mouth from people who are lazy and thoughtless like he is, people who assumed that 4,500 pages about FreeBSD from a lead FreeBSD maintainer must be worth something and didn't bother to check if it was written by an LLM... even though it's 2026.
This book has negative value. It is actively destructive to FreeBSD, even if in the short term it boosts the author's public profile.