OpenBSD Journal
Contributed by ray on from the behind-the-code dept.
“OpenBSD 4.1 has just been released. I interviewed several developers to discuss some of the new features for networking, active porting efforts (landisk and UltraSPARC III), work on SMP, and the improvements in spam fighting.”Check out what your favorite kernel, ports, and userland hackers had to say in this interview!
(Comments are closed)
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By Anonymous Coward (81.83.81.251) on
Comments
By Anonymous Coward (89.59.208.44) on
It worked for me, but now it doesn't...
I found some strange stuff on page two though.. perhaps someone got upset and they removed and arrogant question..
By Karl Sjödahl (Dunceor) on
Works fine here and I can't see any upsetting questions either.
What question would that be?
By Anonymous Coward (151.38.59.133) on
http://www.onlamp.com/lpt/a/7008
By Anonymous Coward (151.188.247.104) on
Just went there; works fine. Maybe the OnLamp site was just getting hit hard at that moment?
By Anonymous Coward (128.171.90.200) on
The section talking about UltraSPARCIII driver development sounded interesting ...
These machines actually make very good machines to do driver development on, since the machine is able to give detailed information on failed bus transfers that will simply lock up your machine on normal i386 hardware.
Comments
By Anonymous Coward (85.178.87.60) on
> The section talking about UltraSPARCIII driver development sounded interesting ...
>
>
>
> These machines actually make very good machines to do driver development on, since the machine is able to give detailed information on failed bus transfers that will simply lock up your machine on normal i386 hardware.
Most interesting for me is the admition that the current SMP implementation is suboptimal.
I strongly do HOPE that this gets a HIGH Priority on ALL Architectures.
I mean... lets face it: Current Software sucks...
You`ve Plenty of CPU-Cores but if you compile something Big, like f.e. Xorg 7.2 you`ve to wait plenty of minutes if not even hours because GCC and other Software don´t use the avaiable CPU-Cores in a optimal way.
Compared to such limitations the OpenBSD SMP-Implementation is kinda great but not realy optimal as pointed out in the Interview.
But propably I missed a GCC-Flag wich makes it aware of more then 1 CPU if it has to compile something complex wich could get done in serval steps...
Comments
By tedu (204.14.154.32) on
> You`ve Plenty of CPU-Cores but if you compile something Big, like f.e. Xorg 7.2 you`ve to wait plenty of minutes if not even hours because GCC and other Software don´t use the avaiable CPU-Cores in a optimal way.
um, make -j?
By Marc Espie (213.41.185.88) espie@openbsd.org on
> > The section talking about UltraSPARCIII driver development sounded interesting ...
> >
> >
> >
> > These machines actually make very good machines to do driver development on, since the machine is able to give detailed information on failed bus transfers that will simply lock up your machine on normal i386 hardware.
>
> Most interesting for me is the admition that the current SMP implementation is suboptimal.
>
> I strongly do HOPE that this gets a HIGH Priority on ALL Architectures.
> I mean... lets face it: Current Software sucks...
>
> You`ve Plenty of CPU-Cores but if you compile something Big, like f.e. Xorg 7.2 you`ve to wait plenty of minutes if not even hours because GCC and other Software don´t use the avaiable CPU-Cores in a optimal way.
>
> Compared to such limitations the OpenBSD SMP-Implementation is kinda great but not realy optimal as pointed out in the Interview.
> But propably I missed a GCC-Flag wich makes it aware of more then 1 CPU if it has to compile something complex wich could get done in serval steps...
>
>
Really weird complaint. Clueless, or troll ?
There is absolutely nothing in gcc that can make it take advantage of multi-cores.
OpenBSD SMP is coarse-grained. But making things work better is really hard. Have you written actual multi-threaded code ? Writing real multi-processor code, when you can't rely on the simplicity of fork() and pipe(), is really hard to do. Most people forget about some race conditions, other people forget that the lib functions they use are not necessarily thread-safe. And then, it doesn't even mean you're going to get faster code. Cache behavior is somewhat tough to predict, you run experiments that run just fine, and then the actual production code is totally suboptimal, either CPU-starved, or memory-starved, or IO-starved, or heck, spending all its time acquiring and releasing semaphores.
As usual, I believe OpenBSD follows the right path: make it correct, then make it fast...
By Anonymous Coward (220.233.181.113) on
you guys keep coming up with serious networking functionality
love the hoststated/pf load balancing, syslog pipes, RSTP and multiple routing tables. looks like you're making a move towards eventually being able to talk MPLS (over ethernet anyway). PF would make an excellent MPLS aware firewall - one trunk in (IOSFW can do this but who do YOU trust?) containing many networks, already bitchin nat/redirect, antispam, OS recognition, logging, etc etc.
would like to know how good/flexible the route filtering/redistribution is (it's obviously pf based so probably V good) - eg can you have multiple vrf specific statics, can you inject routes with hoststaed based on tcp connect or response time? if anyone has had a tinker with it
with an embedded board on steroids this could make underpowered overpriced crisco fistems boxes (probably all of their boxes unless you need WPA - but then there's pfsense) a thing of the past (viva la revolution!) and probably be far more secure and less of a code furball (that would be the availability part of secure)
can anyone recommend any manufacturers? modular chassis, dual chip capable, loads of ram, flash (no HD), dual power, 48v option, lots of ethernet ports (ATM, STM and G703 a bonus) fully obsd compatible and up to date with their donations?
If I don't get a satisfactory answer I may have to start a company in my shed...