4 ms·

"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 suppo

by Canada 10y ago

"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.

i336_ 10y ago
Welp, meant to reply, then completely forgot... > 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!

by Canada 10y ago

i336_ 10y ago

Welp, meant to reply, then completely forgot... > 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!