The reason it came up was a tiny quote from the NetBSD announcement of Luna 68k support which mentions its "rare cousin" the 88k LUNA.
Now that's niche!
Fun fact - the 88k was designed by Mitch Alsup, who also designed SPARC CPUs for Ross, x86s for AMD and others. He is retired, but still active in the comp.arch Usenet newsgroup.
So as long as there are developers who want to do the work to support the 88k LUNA (whatever it is) then it will happen.
More specifically:
You may need locks on a non-SMP system (since you can still have concurrency), but without parallelism you don't need atomics... right?
If you were writing code specifically for the 386, I suppose you could implement all semaphores as critical sections to guard against external interrupts; I see no reason why that wouldn't work. But realistically, that code would be more of a museum piece than something you'd want to maintain in a 2022 operating system.
/me goes back to his polling-only application :)
(we have an interrupt, but it's "the watchdog fired and you're about to die anyway", so not exactly complex to handle...)
i386 ISA is the bare minimum for functioning protected mode to be better than real-mode DOS. i286 protected mode is absolute trash.
i386 is so bad at dealing with SMP primitives, it was standard practice to have a non-SMP kernel. Then, you get into the business of maintaining 2 kernel flavors or a major kernel feature flag.
For those interested, there is a quirky processor mode trick called "unreal mode" that allows flat addressing without switching to protected mode (no protections, just like real-mode DOS).
Intel, as they're known for doing, half-assed many things. Even though the 32 bit mode on the i80386 wouldn't be compatible with i8086 real mode and they could've made vast improvements, they decided to make just a mediocre 32 bit CPU, since they figured most people would just be running it as a super fast i8086.
The m68020 in 1984, by comparison, was much more forward thinking. It had atomic operations, could exist in a multi-processor environment much more easily than an i80386, and it can still run a modern OS (NetBSD) in 2022.
Well, I think the argument being made (implicitly) was:
If Intel had made a decent and capable implementation of 386 with forward looking CPU instructions etc. 386 could have been alive and kicking today in many more operating systems and platforms.
"PC" means personal computer, and the term existed long before the IBM PC, but the term is being used here to refer to the i8086, x86 and amd64 generic platforms. The fact that there's tons of overlap from the original IBM PC with an i8088 to a Compaq 386, then between the i80386 and a PCI Pentium, then more overlap from the Pentium to the Core2Duo, then to a modern UEFI multi-core CPU, means that if people just say, "ISA is dead, so let's rip it out" would lead to a world of pain, unless you want to drop support for every x86 in the world that doesn't use UEFI.
There are lots of people who want to do exactly that, but why? They very untechnically say there's "technical debt", say stupid things like, "people have to spend time supporting that" when open source is volunteer and most code written well will just continue to compile and run well.
Most people forget that the rest of the world that has less money has our leftovers, so some gatekeeper wanting to desupport older hardware he doesn't have WILL affect others. If there's no good technical reason to take it out, don't.
Running on older hardware quickly points out performance regressions. Running on alternate architectures points out issues like bad stack alignment assumptions, endian assumptions or bad word size assumptions. Running on systems with less memory brings light to software that's using too much memory. All of these things benefit someone, and it's pretty shitty to say that people who're less well off should be out of luck because certain people don't want to be told they should code with less assumptions and/or should care when they're told there's something wrong with their code. It happens more than you realize.
But even if people want a "financial" justification for everything, all of those benefits of testing on older hardware help with making sure a system is robust and runs well even on resource constrained embedded platforms. So there's that.
It's funny how some people will scream about not wanting to keep support for hardware less fortunate people have, but will shut up when someone mentions that the same support is important for embedded use.
That might be why it's still supported.
Who is funding OpenBSD these days?
As for funding essentials like electricity, network, hackathons, and unpleasant development work, that would be the OpenBSD foundation (http://www.openbsdfoundation.org/activities.html)
$87.5k in 2022?
That doesn't even pay for a single person after taking the rest of the expenses into account.
Do they all have other jobs and using their spare time to devote to such a serious project?
Yes, except when <daywork> is also OpenBSD related. But that has nothing to do with the foundation.
> $87.5k in 2022?
The year isn't over... and there should be some left from bygone years.
> That doesn't even pay for a single person after taking the rest of the expenses into account.
I'm not aware of a single full-time paid developer, by the OpenBSD foundation. It's more a gig thing. In addition for Hackathons the foundation pays for the venue and network, and the developers usually fly themselves in.
The foundation was founded b.c. the CD sales (back when there were still CDs sold) didn't even cover electricity and network costs of the main site anymore.
It's all done like in the good old days of Linux, before big business stepped in.
An OS release capable of running on the latest hardware in 2022 is still making optimizations for a niche system from the late 80s/early 90s. There's something very beautiful about that.