I'd be interested to hear the author's opinion on pledge.
Also, this article repeatedly points out that OpenBSD did not invent memory hardening techniques, but fails to acknowledge that they were by far the first to ship many of them in a base system by default. As I recall they were the only ones willing to break binary compatibility. Was Openwall was shipping with such protections enabled by default when OpenBSD released W^X? Certainly no other Linux distros were.
I couldn't help wondering that the author had somehow been bitten by something OpenBSD-related, or that he had some kind of spat with some developer(s) somewhere. I wouldn't quite call this FUD, but I don't think it has enough bullet points for the amount of "this is the end of the world" it has in it.
That said, the point about China settling for FreeBSD instead of OpenBSD for their secure computing environment is very interesting. I wonder that OpenBSD may possibly be being distracted by trying to hit some kind of academically "cute" model of functionality, instead of staying grounded and realistic. Or maybe OpenBSD is trying to stay out of the commercial limelight, so is deliberately sidestepping the mainstream enterprise ideas about MAC and so forth?
In any case, I was mildly perturbed to realize that OpenBSD's author also maintains OpenSSH, which has only just now been shaken out of its disturbingly complacent development mindset (http://lwn.net/Articles/702751/ ); OpenBSD is likely to never experience something similar, which is sad - it would be truly interesting to see the level of scurrying and fixing that would happen (and just how much OpenBSD really deserves its security track record)...
1. In my previous comment I meant OpenSSL, not OpenSSH.
2. So I just established that Theo is the author of OpenSSH, while OpenSSL is the large pile of fail. I certainly recognize the difference between the two, but failed at reading while researching about OpenBSD.
Thanks.
And now my view of OpenBSD is a bit more positive :)
Kylin was the Chinese FreeBSD fork (if you can even call it that) started in 2001. This predates the privsep OpenSSH, W^X, chroot Apache, and all that. pf wasn't even released until the end of 2001. There was no support for SMP until 2004, and even now it's far behind everything else.
It's not surprising. OpenBSD isn't suitable for a lot of server tasks now let alone back then.
> Kylin was the Chinese FreeBSD fork (if you can even call it that) started in 2001.
Oh, wow, that was a while ago. I can see why they picked FreeBSD, Linux wasn't really all-around usable back then. Did it even have any security capabilities?
> This predates the privsep OpenSSH, W^X, chroot Apache, and all that. pf wasn't even released until the end of 2001.
Ha.
> There was no support for SMP until 2004, and even now it's far behind everything else.
The SMP thing confuses me to bits. I was talking to the author of MirBSD a little while ago, and couldn't fathom why "no SMP" was a feature (although since MirOS was decented from OpenBSD, maybe it's related to how OpenBSD's SMP is "far behind anything else" as you describe). In any case, SMP is kind of important, if you want to be commercially viable and considered real...
Maybe these are toy UNIXen. Which is totally fine, our brains need a chance to zone out and have delineated spaces to play in that are free of responsibility so we can mess around and learn, but still. Maybe throw in some parodies or something, so that's clear.
> It's not surprising. OpenBSD isn't suitable for a lot of server tasks now let alone back then.
Hmm.
I feel like I'm missing a lot of context here, I wish there was some way I could just go get all the history of it all...
(I discovered Linux in 2006, started running it properly in 08, have felt out of place w/ UNIX ever since)
SELinux was released in 1998. Linux was totally usable back then. I've been using it since 1995.
I've never heard anyone claim lacking SMP support being a feature. In the case of OpenBSD it was just that nobody got around to it until much later. The project never had even close to the number of developers as Linux or FreeBSD.
Back in the 90s OpenBSD focused on code audit and fixing bugs rather than adding features. I found it most useful as a firewall and nameserver because it came with ipf and they included BIND with chroot support built in. Installation was dead simple. As long as you stuck to well supported hardware, it just worked out of the box. Back then SMP meant you had multiple physical CPUs, and that wasn't generally necessary for systems dealing with 100mbit interfaces. If you needed to deal with a lot of traffic you had to get real routers because the PC wasn't great at handling tons of interrupts.
In 2000 or 2001 the author of ipf decided to "clarify" his license, asserting that it could not be shipped with patches. OpenBSD deleted it from the tree and pf was born. They also forked SSH over licensing issues in 1999, but at the time there wasn't any great benefit to using it over the original version.
Starting in the early 2000s OpenBSD added a lot of really useful networking tools. The carp and pfsync interfaces let you run redundant firewalls very easily. Support for syncing the dhcpd state was added. For managing wireless networks hostapd. For load balancing tasks relayd. VPN setup was simplified greatly with ipsecctl. They added privsep to OpenSSH. They created OpenNTPD in response to many ntpd vulnerabilities. They made buffer overflow protections the default. They reduced privileged programs left and right. And everything remained simple with accurate man pages. So SMP support was lacking? Not such a big deal in exchange for a system that just worked.
The problem is when you need to run a big file server, database server, web server, etc. For such uses having good SMP helps. Having ZFS helps. Having packages for the boatload of dependencies your shiny new web framework requires is critical. And you want binary updates, which OpenBSD doesn't officially have.
> Controversial decisions are often made differently from OpenBSD; for instance, there won't be any support for SMP in MirOS.
Not really sure how to interpret that ^ but it sounds like a deliberate stand to me, like it's a feature. I totally get there's some context there, but I'm not sure what exactly it is.
> In the case of OpenBSD it was just that nobody got around to it until much later.
Mmm.
> The project never had even close to the number of developers as Linux or FreeBSD.
I see. I (genuinely) wonder why.
> Back in the 90s OpenBSD focused on code audit and fixing bugs rather than adding features. I found it most useful as a firewall and nameserver because it came with ipf and they included BIND with chroot support built in.
Interesting.
> Installation was dead simple. As long as you stuck to well supported hardware, it just worked out of the box.
Ha :P
How good was hardware support?
> Back then SMP meant you had multiple physical CPUs, and that wasn't generally necessary for systems dealing with 100mbit interfaces.
Right. That makes sense.
> If you needed to deal with a lot of traffic you had to get real routers because the PC wasn't great at handling tons of interrupts.
TIL, so that's why...
I'm curious where I can learn more about interrupts (and the latest developments there), incidentally - I have far too little knowledge about hardware than I would like.
> In 2000 or 2001 the author of ipf decided to "clarify" his license, asserting that it could not be shipped with patches. OpenBSD deleted it from the tree and pf was born.
* Shakes head *
> They also forked SSH over licensing issues in 1999, but at the time there wasn't any great benefit to using it over the original version.
How'd they manage to fork it? Was the old license fork-compatible?
> Starting in the early 2000s OpenBSD added a lot of really useful networking tools. The carp and pfsync interfaces let you run redundant firewalls very easily. Support for syncing the dhcpd state was added. For managing wireless networks hostapd. For load balancing tasks relayd. VPN setup was simplified greatly with ipsecctl.
I see, I get the impression they want to make an awesome router that's resilient to attack.
And then I look at the fact that OpenBSD is the only BSD advertising working hibernation support... and I get really confused about what, exactly, OpenBSD is trying to do/be :P
> They added privsep to OpenSSH. They created OpenNTPD in response to many ntpd vulnerabilities. They made buffer overflow protections the default. They reduced privileged programs left and right. And everything remained simple with accurate man pages.
Nice. Especially the manpages thing...
> So SMP support was lacking? Not such a big deal in exchange for a system that just worked.
Mmm.
> The problem is when you need to run a big file server, database server, web server, etc. For such uses having good SMP helps. Having ZFS helps.
Yep.
> Having packages for the boatload of dependencies your shiny new web framework requires is critical.
Yep :(
> And you want binary updates, which OpenBSD doesn't officially have.
...I can't say I like juggling source-level updates (never found Gentoo appetizing, at least), especially in a virtualized environment.
"MirOS BSD is a secure operating system from the BSD family for 32-bit i386 and sparc systems"
OpenBSD dropped 32-bit sparc support. And 32-bit Intel CPU support only? MirOS isn't interested in supporting any modern hardware. So yeah, why bother with SMP...
OpenBSD's hardware support back then wasn't bad. It's just that you'd definitely want to check that what you were buying was supported before you bought it rather than just assume everything's going to work.
The OpenSSH fork was based off the last BSD licensed release of SSH. SSH authors decided to adopt a more restrictive license. Within 5 years 90% of internet facing SSH servers were running OpenSSH. The deal with OpenBSD is that it's great if you do the same things as their developers. If not then you're out of luck. Apparently they like building networks and closing the lids of their laptops.
Regarding different operating systems SMP support and your question of interrupt handling, you should consult OS architecture books. In a nutshell for SMP:
How well the kernel's scheduler can make userland processes and threads run concurrently on different CPUs or cores is a big deal. This isn't easy, because you have situations where certain cores may share cache and others don't.
How well the kernel can run itself concurrently is also a big deal. If the kernel can only run on a single core at once then even if user processes can run on different cores there will be contention when they make system calls. For the kernel to be reading data from a network card, while writing data to a filesystem, while comparing a packet against the firewall ruleset, while executing the scheduler, while allocating memory to some process, all at the same time on different cores requires fine grained locking. (Or possibly lock free data structures where possible) With only a single CPU the kernel can just assume its memory is consistent. Once the kernel is running concurrently great care must be taken to prevent accidental corruption. Mistakes result in deadlock, kernel panic, or worse.
Linux, FreeBSD, Windows, and Solaris for example, have all solved this problem much better than OpenBSD has for a long time. OpenBSD has only begun to address this quite recently.
In a nutshell for interrupt handling: Say you're routing frames between several Ethernet interfaces. Nevermind a proper firewall which would be much worse, you're just bridging like a switch.
When a frame comes in on a port you get an interrupt and context switch into the kernel. Then you have to read at least the destination address into main memory so you can compare it to your MAC table and know how to handle it. Then you need to copy the whole frame to the appropriate outputs. This is very slow compared to the CAM table lookup that dedicated switch hardware uses. Even though a general purpose CPU can do some really impressive things, if you add enough network interfaces and a high enough packet rate to a PC it won't keep up.
> OpenBSD dropped 32-bit sparc support. And 32-bit Intel CPU support only? MirOS isn't interested in supporting any modern hardware. So yeah, why bother with SMP...
This sort of thing confuses me a lot. I see it like a total waste of effort to go to the lengths of maintaining a UNIX (BSD) variant (kernel and everything) if your work isn't going to have a real-world use... I mean locking yourself into x86_32 and SPARC is basically a death knell, nobody will consider the software as a serious product.
> OpenBSD's hardware support back then wasn't bad. It's just that you'd definitely want to check that what you were buying was supported before you bought it rather than just assume everything's going to work.
Ah, like Linux was at one point. Makes total sense.
> The OpenSSH fork was based off the last BSD licensed release of SSH.
Ah, makes sense.
> SSH authors decided to adopt a more restrictive license. Within 5 years 90% of internet facing SSH servers were running OpenSSH.
Heh. Like the egcc war thing...
> The deal with OpenBSD is that it's great if you do the same things as their developers. If not then you're out of luck.
Sounds like Google :P ("nah, don't think anybody's using Reader or Wave"...)
> Apparently they like building networks and closing the lids of their laptops.
And now I'm imagining half-second clips of those two things happening one after the other, in an infinite loop...
> Regarding different operating systems SMP support and your question of interrupt handling, you should consult OS architecture books.
OH, so THAT's why people design OSes... I finally get it. To properly make sense of hardware, and also understand the practical issues of multitasking and such. Thanks, I've always been torn about starting a toy OS project, I finally see the rationale behind it now, will definitely be poking the subject at some point (probably for multiple architectures, too!).
> In a nutshell for SMP:
> (...)
> Linux, FreeBSD, Windows, and Solaris for example, have all solved this problem much better than OpenBSD has for a long time. OpenBSD has only begun to address this quite recently.
Hah. I see. (Where might I read about the work they're doing?)
> In a nutshell for interrupt handling: Say you're routing frames between several Ethernet interfaces. Nevermind a proper firewall which would be much worse, you're just bridging like a switch.When a frame comes in on a port you get an interrupt and context switch into the kernel. Then you have to read at least the destination address into main memory so you can compare it to your MAC table and know how to handle it. Then you need to copy the whole frame to the appropriate outputs. This is very slow compared to the CAM table lookup that dedicated switch hardware uses. Even though a general purpose CPU can do some really impressive things, if you add enough network interfaces and a high enough packet rate to a PC it won't keep up.
That's... not really an easy problem to solve, I get it now.
Best place to follow OpenBSD happenings is on their mailing lists and on undeadly.org.
Building a toy OS or porting an existing one to a new CPU is a big accomplishment in my opinion. If you can do it you'll know a heck of a lot more about OS building than I do!
Hardware has long been a mystery to me, but it never really clicked (the epiphany never really happened) that the direction to go in to solve that mystery was to mess around with writing a toy OS. I get that now (and finally understand the raft of almost-useless toy OSes out there).
Thankfully, I have an idea of the simple UI environment I'd want to build on top (I've actually been noncomittally noodling a few ideas for some time), and would very likely be able to nicely make do with cooperating multitasking, etc - so it shouldn't be too hard. Which is nice.
Some of my ideas involve working with a number of different architectures, too (ARM, 68k, etc), so I'd finally be learning asm for several different chipsets, as well.
Stares at atrophied discipline muscles
...Eventually.
As an aside, I have a possible startpoint that may be interesting: a GSoC project got Lua running under SYSLINUX a couple years ago. One of the examples showed how to call VBE to set the graphics mode, and plot pixels. SYSLINUX does UEFI now. If a Lua-callable EFI graphics library became available... ooooo. Literally all CPUs are so fast at 2D, you could write whole UXes on top of that. (Maybe add AC97 too, and finally put the MOD/WAV player in gfxboot out of its misery.)
15 comments
[ 3.4 ms ] story [ 15.0 ms ] threadAlso, this article repeatedly points out that OpenBSD did not invent memory hardening techniques, but fails to acknowledge that they were by far the first to ship many of them in a base system by default. As I recall they were the only ones willing to break binary compatibility. Was Openwall was shipping with such protections enabled by default when OpenBSD released W^X? Certainly no other Linux distros were.
I couldn't help wondering that the author had somehow been bitten by something OpenBSD-related, or that he had some kind of spat with some developer(s) somewhere. I wouldn't quite call this FUD, but I don't think it has enough bullet points for the amount of "this is the end of the world" it has in it.
That said, the point about China settling for FreeBSD instead of OpenBSD for their secure computing environment is very interesting. I wonder that OpenBSD may possibly be being distracted by trying to hit some kind of academically "cute" model of functionality, instead of staying grounded and realistic. Or maybe OpenBSD is trying to stay out of the commercial limelight, so is deliberately sidestepping the mainstream enterprise ideas about MAC and so forth?
In any case, I was mildly perturbed to realize that OpenBSD's author also maintains OpenSSH, which has only just now been shaken out of its disturbingly complacent development mindset (http://lwn.net/Articles/702751/ ); OpenBSD is likely to never experience something similar, which is sad - it would be truly interesting to see the level of scurrying and fixing that would happen (and just how much OpenBSD really deserves its security track record)...
For a counterpoint, I also read this nice and positive argument recently: http://cfenollosa.com/blog/openbsd-from-a-veteran-linux-user...
And I found this page a while back, on OpenBSD as a router: http://www.skeptech.org/blog/2013/01/13/unscrewed-a-story-ab...
Indeed.
1. In my previous comment I meant OpenSSL, not OpenSSH.
2. So I just established that Theo is the author of OpenSSH, while OpenSSL is the large pile of fail. I certainly recognize the difference between the two, but failed at reading while researching about OpenBSD.
Thanks.
And now my view of OpenBSD is a bit more positive :)
It's not surprising. OpenBSD isn't suitable for a lot of server tasks now let alone back then.
Oh, wow, that was a while ago. I can see why they picked FreeBSD, Linux wasn't really all-around usable back then. Did it even have any security capabilities?
> This predates the privsep OpenSSH, W^X, chroot Apache, and all that. pf wasn't even released until the end of 2001.
Ha.
> There was no support for SMP until 2004, and even now it's far behind everything else.
The SMP thing confuses me to bits. I was talking to the author of MirBSD a little while ago, and couldn't fathom why "no SMP" was a feature (although since MirOS was decented from OpenBSD, maybe it's related to how OpenBSD's SMP is "far behind anything else" as you describe). In any case, SMP is kind of important, if you want to be commercially viable and considered real...
Maybe these are toy UNIXen. Which is totally fine, our brains need a chance to zone out and have delineated spaces to play in that are free of responsibility so we can mess around and learn, but still. Maybe throw in some parodies or something, so that's clear.
> It's not surprising. OpenBSD isn't suitable for a lot of server tasks now let alone back then.
Hmm.
I feel like I'm missing a lot of context here, I wish there was some way I could just go get all the history of it all...
(I discovered Linux in 2006, started running it properly in 08, have felt out of place w/ UNIX ever since)
And with "did it even have any security capabilities" I was referring to Linux (just to be clear).
I've never heard anyone claim lacking SMP support being a feature. In the case of OpenBSD it was just that nobody got around to it until much later. The project never had even close to the number of developers as Linux or FreeBSD.
Back in the 90s OpenBSD focused on code audit and fixing bugs rather than adding features. I found it most useful as a firewall and nameserver because it came with ipf and they included BIND with chroot support built in. Installation was dead simple. As long as you stuck to well supported hardware, it just worked out of the box. Back then SMP meant you had multiple physical CPUs, and that wasn't generally necessary for systems dealing with 100mbit interfaces. If you needed to deal with a lot of traffic you had to get real routers because the PC wasn't great at handling tons of interrupts.
In 2000 or 2001 the author of ipf decided to "clarify" his license, asserting that it could not be shipped with patches. OpenBSD deleted it from the tree and pf was born. They also forked SSH over licensing issues in 1999, but at the time there wasn't any great benefit to using it over the original version.
Starting in the early 2000s OpenBSD added a lot of really useful networking tools. The carp and pfsync interfaces let you run redundant firewalls very easily. Support for syncing the dhcpd state was added. For managing wireless networks hostapd. For load balancing tasks relayd. VPN setup was simplified greatly with ipsecctl. They added privsep to OpenSSH. They created OpenNTPD in response to many ntpd vulnerabilities. They made buffer overflow protections the default. They reduced privileged programs left and right. And everything remained simple with accurate man pages. So SMP support was lacking? Not such a big deal in exchange for a system that just worked.
The problem is when you need to run a big file server, database server, web server, etc. For such uses having good SMP helps. Having ZFS helps. Having packages for the boatload of dependencies your shiny new web framework requires is critical. And you want binary updates, which OpenBSD doesn't officially have.
> SELinux was released in 1998. Linux was totally usable back then. I've been using it since 1995.
Oh, okay then. Nice...
> I've never heard anyone claim lacking SMP support being a feature.
https://www.mirbsd.org/about.htm:
> Controversial decisions are often made differently from OpenBSD; for instance, there won't be any support for SMP in MirOS.
Not really sure how to interpret that ^ but it sounds like a deliberate stand to me, like it's a feature. I totally get there's some context there, but I'm not sure what exactly it is.
> In the case of OpenBSD it was just that nobody got around to it until much later.
Mmm.
> The project never had even close to the number of developers as Linux or FreeBSD.
I see. I (genuinely) wonder why.
> Back in the 90s OpenBSD focused on code audit and fixing bugs rather than adding features. I found it most useful as a firewall and nameserver because it came with ipf and they included BIND with chroot support built in.
Interesting.
> Installation was dead simple. As long as you stuck to well supported hardware, it just worked out of the box.
Ha :P
How good was hardware support?
> Back then SMP meant you had multiple physical CPUs, and that wasn't generally necessary for systems dealing with 100mbit interfaces.
Right. That makes sense.
> If you needed to deal with a lot of traffic you had to get real routers because the PC wasn't great at handling tons of interrupts.
TIL, so that's why...
I'm curious where I can learn more about interrupts (and the latest developments there), incidentally - I have far too little knowledge about hardware than I would like.
> In 2000 or 2001 the author of ipf decided to "clarify" his license, asserting that it could not be shipped with patches. OpenBSD deleted it from the tree and pf was born.
* Shakes head *
> They also forked SSH over licensing issues in 1999, but at the time there wasn't any great benefit to using it over the original version.
How'd they manage to fork it? Was the old license fork-compatible?
> Starting in the early 2000s OpenBSD added a lot of really useful networking tools. The carp and pfsync interfaces let you run redundant firewalls very easily. Support for syncing the dhcpd state was added. For managing wireless networks hostapd. For load balancing tasks relayd. VPN setup was simplified greatly with ipsecctl.
I see, I get the impression they want to make an awesome router that's resilient to attack.
And then I look at the fact that OpenBSD is the only BSD advertising working hibernation support... and I get really confused about what, exactly, OpenBSD is trying to do/be :P
> They added privsep to OpenSSH. They created OpenNTPD in response to many ntpd vulnerabilities. They made buffer overflow protections the default. They reduced privileged programs left and right. And everything remained simple with accurate man pages.
Nice. Especially the manpages thing...
> So SMP support was lacking? Not such a big deal in exchange for a system that just worked.
Mmm.
> The problem is when you need to run a big file server, database server, web server, etc. For such uses having good SMP helps. Having ZFS helps.
Yep.
> Having packages for the boatload of dependencies your shiny new web framework requires is critical.
Yep :(
> And you want binary updates, which OpenBSD doesn't officially have.
...I can't say I like juggling source-level updates (never found Gentoo appetizing, at least), especially in a virtualized environment.
OpenBSD dropped 32-bit sparc support. And 32-bit Intel CPU support only? MirOS isn't interested in supporting any modern hardware. So yeah, why bother with SMP...
OpenBSD's hardware support back then wasn't bad. It's just that you'd definitely want to check that what you were buying was supported before you bought it rather than just assume everything's going to work.
The OpenSSH fork was based off the last BSD licensed release of SSH. SSH authors decided to adopt a more restrictive license. Within 5 years 90% of internet facing SSH servers were running OpenSSH. The deal with OpenBSD is that it's great if you do the same things as their developers. If not then you're out of luck. Apparently they like building networks and closing the lids of their laptops.
Regarding different operating systems SMP support and your question of interrupt handling, you should consult OS architecture books. In a nutshell for SMP:
How well the kernel's scheduler can make userland processes and threads run concurrently on different CPUs or cores is a big deal. This isn't easy, because you have situations where certain cores may share cache and others don't.
How well the kernel can run itself concurrently is also a big deal. If the kernel can only run on a single core at once then even if user processes can run on different cores there will be contention when they make system calls. For the kernel to be reading data from a network card, while writing data to a filesystem, while comparing a packet against the firewall ruleset, while executing the scheduler, while allocating memory to some process, all at the same time on different cores requires fine grained locking. (Or possibly lock free data structures where possible) With only a single CPU the kernel can just assume its memory is consistent. Once the kernel is running concurrently great care must be taken to prevent accidental corruption. Mistakes result in deadlock, kernel panic, or worse.
Linux, FreeBSD, Windows, and Solaris for example, have all solved this problem much better than OpenBSD has for a long time. OpenBSD has only begun to address this quite recently.
In a nutshell for interrupt handling: Say you're routing frames between several Ethernet interfaces. Nevermind a proper firewall which would be much worse, you're just bridging like a switch.
When a frame comes in on a port you get an interrupt and context switch into the kernel. Then you have to read at least the destination address into main memory so you can compare it to your MAC table and know how to handle it. Then you need to copy the whole frame to the appropriate outputs. This is very slow compared to the CAM table lookup that dedicated switch hardware uses. Even though a general purpose CPU can do some really impressive things, if you add enough network interfaces and a high enough packet rate to a PC it won't keep up.
> OpenBSD dropped 32-bit sparc support. And 32-bit Intel CPU support only? MirOS isn't interested in supporting any modern hardware. So yeah, why bother with SMP...
This sort of thing confuses me a lot. I see it like a total waste of effort to go to the lengths of maintaining a UNIX (BSD) variant (kernel and everything) if your work isn't going to have a real-world use... I mean locking yourself into x86_32 and SPARC is basically a death knell, nobody will consider the software as a serious product.
> OpenBSD's hardware support back then wasn't bad. It's just that you'd definitely want to check that what you were buying was supported before you bought it rather than just assume everything's going to work.
Ah, like Linux was at one point. Makes total sense.
> The OpenSSH fork was based off the last BSD licensed release of SSH.
Ah, makes sense.
> SSH authors decided to adopt a more restrictive license. Within 5 years 90% of internet facing SSH servers were running OpenSSH.
Heh. Like the egcc war thing...
> The deal with OpenBSD is that it's great if you do the same things as their developers. If not then you're out of luck.
Sounds like Google :P ("nah, don't think anybody's using Reader or Wave"...)
> Apparently they like building networks and closing the lids of their laptops.
And now I'm imagining half-second clips of those two things happening one after the other, in an infinite loop...
> Regarding different operating systems SMP support and your question of interrupt handling, you should consult OS architecture books.
OH, so THAT's why people design OSes... I finally get it. To properly make sense of hardware, and also understand the practical issues of multitasking and such. Thanks, I've always been torn about starting a toy OS project, I finally see the rationale behind it now, will definitely be poking the subject at some point (probably for multiple architectures, too!).
> In a nutshell for SMP:
> (...)
> Linux, FreeBSD, Windows, and Solaris for example, have all solved this problem much better than OpenBSD has for a long time. OpenBSD has only begun to address this quite recently.
Hah. I see. (Where might I read about the work they're doing?)
> In a nutshell for interrupt handling: Say you're routing frames between several Ethernet interfaces. Nevermind a proper firewall which would be much worse, you're just bridging like a switch. When a frame comes in on a port you get an interrupt and context switch into the kernel. Then you have to read at least the destination address into main memory so you can compare it to your MAC table and know how to handle it. Then you need to copy the whole frame to the appropriate outputs. This is very slow compared to the CAM table lookup that dedicated switch hardware uses. Even though a general purpose CPU can do some really impressive things, if you add enough network interfaces and a high enough packet rate to a PC it won't keep up.
That's... not really an easy problem to solve, I get it now.
Thanks for the explanations!
Building a toy OS or porting an existing one to a new CPU is a big accomplishment in my opinion. If you can do it you'll know a heck of a lot more about OS building than I do!
Hardware has long been a mystery to me, but it never really clicked (the epiphany never really happened) that the direction to go in to solve that mystery was to mess around with writing a toy OS. I get that now (and finally understand the raft of almost-useless toy OSes out there).
Thankfully, I have an idea of the simple UI environment I'd want to build on top (I've actually been noncomittally noodling a few ideas for some time), and would very likely be able to nicely make do with cooperating multitasking, etc - so it shouldn't be too hard. Which is nice.
Some of my ideas involve working with a number of different architectures, too (ARM, 68k, etc), so I'd finally be learning asm for several different chipsets, as well.
Stares at atrophied discipline muscles
...Eventually.
As an aside, I have a possible startpoint that may be interesting: a GSoC project got Lua running under SYSLINUX a couple years ago. One of the examples showed how to call VBE to set the graphics mode, and plot pixels. SYSLINUX does UEFI now. If a Lua-callable EFI graphics library became available... ooooo. Literally all CPUs are so fast at 2D, you could write whole UXes on top of that. (Maybe add AC97 too, and finally put the MOD/WAV player in gfxboot out of its misery.)