Also, I think FreeBSD eliminated the giant lock ~10 years ago and maintains similarly good documentation. It’s just a matter of priorities, and SMP scalability/high performance has never been on the top of the OpenBSD list.
Yes, and goals. OpenBSD is much more conservative with regard to features, and focuses on security, and that results in a more secure system overall. If you need to eek out every last percent of performance, use something else. If you want to worry less about security on a system that is fairly exposed (e.g. a firewall), then it can be an extremely good fit. For example, here's a comparison of security advisories for the main OpenBSD, FreeBSD and Linux projects (that is, not separated and exported items like OpenSSH).[1][2] While I'm sure these lists have their problems, they are interesting. Specifically, the number of exploits column...
On the other hand some of this can be explained by linux being a higher value target with more security research around it. If I find a remote exploit in the linux kernel I have a few billion targets, but if I find one in a *BSD I probably have a few million, tops.
I thinks its a greyscale and have always been. Silly things like floppy (that noone uses) on fbsd used to attach with [GIANT LOCKED] for the longest time (if not still) but it doesn't matter. You would not call fbsd still under GL just because 1.44MB floppy drivers don't get any attention. So its not a binary on-or-off on any OS, its a process of unlocking one part at a time, out of hundreds, thousands of small subsystems and drivers without causing races. OpenBSD is most certainly behind, but there is no nice line over which you can say "Ah, now its not GL anymore", since there will be some part somewhere for some arch where you don't care that still retains the lock, and there were parts from day #1 that was completely unlocked on obsd like the syscall getpid() in all its triviality and race-free-ness.
