FreeBSD Device Drivers Book(github.com)
github.com
FreeBSD Device Drivers Book
https://github.com/ebrandi/FDD-book
46 comments
My exposure to FreeBSD has been mostly through routers and firewalls, plus reading about jails and finding the concept genuinely impressive. Always wanted to dig deeper but the existing material assumes you already know the things I was hoping to learn. A book that explicitly starts before that wall sounds like exactly what's been missing. Going to give it a real shot.
For me, boot environments are the killer feature. I think it's the only mainstream OS to really support the concept. Void linux (which is great) and (probably?) the Illumos distributions are the other open source choices, but those are much more niche. Or you could bolt it on to another linux distro using ZBM, but then you're on your own.
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.
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.
That's a really compelling workflow. On the Linux side I've heard of openSUSE's MicroOS doing something conceptually similar with BTRFS snapshots and atomic transactional updates, though I haven't actually run it. Different mechanism but it sounds like the same instinct. Never let the running system get into an inconsistent state during an upgrade. The "boot just once" plus jail-the-clone-to-upgrade combo you described sounds genuinely clever, hadn't realised the bectl integration was that smooth. Void Linux is just a name to me at this point, might be time to actually look it up.
> On the Linux side I've heard of openSUSE's MicroOS doing something conceptually similar with BTRFS snapshots and atomic transactional updates, though I haven't actually run it. Different mechanism but it sounds like the same instinct.
I have run the Kalpa Desktop, which is basically MicroOS + KDE, and yes that's almost exactly the same setup; updates/changes are done using transactional-update, which AIUI performs the change in a new root snapshot/filesystem and then you reboot to make it take effect. Honestly a very nice system, although I eventually abandoned it because I was ultimately unwilling to run on BTRFS (which I absolutely do not trust).
I have run the Kalpa Desktop, which is basically MicroOS + KDE, and yes that's almost exactly the same setup; updates/changes are done using transactional-update, which AIUI performs the change in a new root snapshot/filesystem and then you reboot to make it take effect. Honestly a very nice system, although I eventually abandoned it because I was ultimately unwilling to run on BTRFS (which I absolutely do not trust).
> For me, boot environments are the killer feature. I think it's the only mainstream OS to really support the concept. Void linux (which is great) and (probably?) the Illumos distributions are the other open source choices, but those are much more niche. Or you could bolt it on to another linux distro using ZBM, but then you're on your own.
I think (Open)SUSE does something similar using BTRFS snapshots. But yes, ZFS-backed BEs are the best IMHO:) OpenIndiana still does them, of course, but yeah that's sadly niche.
I think (Open)SUSE does something similar using BTRFS snapshots. But yes, ZFS-backed BEs are the best IMHO:) OpenIndiana still does them, of course, but yeah that's sadly niche.
A Brief Word About Btrfs
A fair-minded reader will point out that Linux has its own copy-on-write filesystem:
Btrfs. And openSUSE's integration of Btrfs with Snapper deserves genuine credit.
Snapper, developed by Arvin Schnell at SUSE and first shipped with openSUSE
12.1 in November 2011, creates automatic snapshots in pre/post pairs around every
zypper transaction. GRUB is patched to offer a submenu for booting from snap‐
shots. The rollback workflow is coherent: reboot, select the snapshot, verify, run
snapper rollback , reboot again. On openSUSE, this works out of the box.
The caveats are worth mentioning. Btrfs's RAID5 and RAID6 implementations
still carry an official data loss warning in the documentation, a caveat that has per‐
sisted for years. ZFS's equivalent (RAIDZ, RAIDZ2, RAIDZ3) has been production-
ready since 2005. Btrfs has no equivalent to zfs send and zfs receive for efficient
incremental replication between hosts. And while Btrfs reached general production
readiness around 2015, ZFS had a decade's head start.
None of this makes Btrfs a bad filesystem. It makes it a younger one. And the
openSUSE team deserves genuine credit for building what they have built.
But even in the best case, the Btrfs workflow on openSUSE is a distribution-level
achievement. It is SUSE's integration work on top of a filesystem, a bootloader, and a
snapshot manager that are all developed separately. The GRUB integration is
openSUSE-specific; other distributions using Snapper do not get the boot-from-
snapshot feature without additional patching. The whole edifice is one team's excel‐
lent work within the assembled model. On FreeBSD, it is one team, one repository,
one design, one release.
ublue and alike accomplish similar on Linux, it looks a bit wonky on the first glance, but is pretty good day to day
openSUSE with snapper does this automatically. It's far more mainstream than FreeBSD.
Have you poked through the handbook or Absolute FreeBSD? Those are both great starting points
Hadn't actually heard of either, thanks for the pointers. Will start with the Handbook.
This is a huge book!
I would like to know if a LLM was involved in the writing process or if this is the product of a human.
"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 doesn't directly answer your question though.
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.
Yes I saw that too.
Even if it was, the author is not a random person and is part of the FreeBSD team and I'd rather trust them to write the book than someone else outside of the organization.
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.
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.
I guarantee they didn't read a single word of this book. Look at the introduction to C and tell me that
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.
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.
Yep. It's not the best intro to C, for sure. I learned C when I was a teenager, from K&R C second edition, and several Amiga-specific books ("Amiga C for Beginners", for one.)
I'm not reading that whole thing right now (that is a lot of text), but I read as far as "What Is a Variable?" and nothing stands out as bad or AI-written. What problems do you see?
> This book is a dishonest AI scam.
Indeed! I read through a couple of paragraphs. Each begins with a bloated introduction where each sentence repeats same idea many times in different words. Lot's of bullets repeating same statement. That's exactly how LLM scam looks like. The whole book is full of water. It can be reduced in size by a factor of 5.
Indeed! I read through a couple of paragraphs. Each begins with a bloated introduction where each sentence repeats same idea many times in different words. Lot's of bullets repeating same statement. That's exactly how LLM scam looks like. The whole book is full of water. It can be reduced in size by a factor of 5.
It's a free book, he's not selling you anything.
Being LLM slop in particular, this book cost way more of my time than it should have. It really does look superficially competent, until you realize that competence is paragraph-to-paragraph, not section-to-section.
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.
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.
> This book has negative value. It is actively destructive to FreeBSD, even if in the short term it boosts the author's public profile.
I won't be that radical, the book still has value. There are many useful code samples with descriptions and explanations of concepts I did not know before. But to get to them one has to dig through a forrest of useless tokens. Someone has to pass it through an LLM and publish distilled edition. :-)
I won't be that radical, the book still has value. There are many useful code samples with descriptions and explanations of concepts I did not know before. But to get to them one has to dig through a forrest of useless tokens. Someone has to pass it through an LLM and publish distilled edition. :-)
I am pretty sure he's been working on this book since before LLMs were a thing. He's also not the kind of person who'd just delegate his passion to a machine.
There is nothing wrong with using an LLM so long as a human takes ownership for the artefact (be that books, code etc).
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 ?
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 ?
There is something wrong with it because LLMs are really not capable of writing a useful book, and this book is 100% LLM slop.
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"
Edit: I mean look at the intro to for loops. This is supposed to be for total beginners. Example 1:
>> Repeat while i < 10
>> Increment i each time by 1 (i++)
Example 2:
>> * 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.
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);
}
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);
}
>> 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);
}
>> * 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.
[deleted]
> I assume Brandi is just trying to make a quick buck,
By publishing a free book without even a way to donate?
By publishing a free book without even a way to donate?
its FREE. no ads nothing.
you are realy anti LLM and thats fine but dont let yourself be total blinded.
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.
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.
theres some questionable quality content in the book, but lets be fair 4.5k pages is hard to manage.
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 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.)
Books are great. Even if they are not perfect.
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 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
> theres some questionable quality content in the book, but lets be fair 4.5k pages is hard to manage.
Could you be more specific? Maybe open an issue listing points for possible improvement?
Could you be more specific? Maybe open an issue listing points for possible improvement?
Edson Brandi is a very clever guy, and I'm surprised he managed to pull this off considering his other professional engagements.
For embedded/kernel programmers: Is there a linux equivalent of this book?
[deleted]
very lucid idea for a book, though the ai generated cover doesn't inspire much confidence in me.
Never seen a book written that incorporates the programming language as part of the learning material.
Awesome work!
I await the Linux version :)
Awesome work!
I await the Linux version :)
Wow, that's amazing:
> 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!
> 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!
Quite common back when books were the main learning source.
Much nicer than the current approach of throwing you in the deep end and expecting you to already know everything the author does.
Considering how passionate the author is about BSD, I wouldn't hold my breath.