OpenBSD 3.7: The Wizard of OSby Federico Biancuzzi
Today the OpenBSD project announced the new 3.7 release. This is the
first release to support newer wireless chipsets, especially for 802.11g,
thanks to a big activism campaign lead by project leader Theo de Raadt. It's
now possible to create a portable access point with a tiny PDA using the Zaurus
port, too. As usual, there are a lot of other big and small changes, such as the
import of Xorg, the jump towards
gcc3, and a feature to update your installed
packages automagically. Discover the details behind the scenes in this
interview that Federico Biancuzzi had with several OpenBSD developers.
Many people will probably enjoy this release especially for the rich set of new Wi-Fi chipsets supported. It took years, but now you support them with total compliance with your goals and license. Which vendors would you define as open-source-friendly and which as unsupportive?
Damien Bergamini: Ralink Tech. and Realtek have been very
friendly by providing us documentation for their wireless chipsets. Ralink
Tech. gave us the spec for their RT2500USB 802.11 b/g chipset and about one
week later, we had a working driver (
ural) for it, just in time before 3.7 code
freeze. The work on this driver now continues in OpenBSD-current and I'm adding
advanced functionalities like HostAP mode support (the capability for a host to
act as an access point). OpenBSD was the very first operating system to provide
an open source driver for the RT2500USB chipset, and AFAIK it is still the only
one to support this chipset today. I know some Linux users that feel jealous
about this ;)
It is important to show vendors what they can benefit at no cost when cooperating with us. We are very respectful toward these vendors and if they ask us not to spread the documentation around, we respect this. But we do not sign NDAs.
OTOH, Intel has been quite uncooperative by refusing to give us the right to
redistribute the binary firmware images for their PRO/Wireless
2100/2200BG/2915ABG adapters (Centrino). As a consequence, although drivers
for these adapters (
iwi) are included into OpenBSD 3.7, they do not
work out of the box. Users must download the firmware images by hand on the
Intel web site and they are invited to complain to Intel about this before
Is there anything that our readers could do to help you succeed?
Damien Bergamini: Buy hardware made by open-source-friendly vendors (there is almost always a choice) and continue to contact the closed vendors. It has proven to be effective in the past.
And to the Linux "vendors" that regardlessly ship non-free firmware images with their OSes, I'd say that they are playing against their camp. Why would vendors ever change their policies if such things are accepted by the open source community?
I read that you have a plan to create a global
tool to manage all of the different RAID controllers, but you are missing the
necessary documentation from some vendors. Which vendors would you define as
open-source-friendly and which as unsupportive?
Marco Peereboom: Yes, work has started on a tool that will
do universal RAID management; it is actually called
because it uses the
ioctl tunnel device. The tool you
raidctl(4), is used for software RAID instead.
The idea behind
bioctl(8) is to do as much RAID management as
possible inside of the driver whereas the userland portion remains as simple as
Unfortunately, there are still vendors out there that believe that there is IP inside of a hardware API. In my experience this is mostly nonsense, and whenever there is IP hidden inside an API it only means that the device was architected poorly. We are talking about filling in some sort of structure, sending it to the device and awaiting an answer either directly or through a callback. There is no secret sauce hidden in these numbers that enables competitors to magically understand what goes on in the firmware.
Reverse-engineering hardware is all about motivation and resources. If a vendor is motivated enough, it will have to spend considerable resources on people with specialized knowledge and equipment to X-ray a board in order to obtain the schematics. It is even harder to reverse engineer programmable chips like FPGAs and CPLDs. Compared to this, reverse-engineering a software API is trivial. Hiding an API does not help a vendor in any way, shape, or form, and it really is silly to keep it hidden as if the farm depends on it.
This release fixes the mirroring mode in
types of choices does an OpenBSD user have to set up a RAID array
Michael Shalayeff: As usual, two choices: software or
hardware. All of the drivers we have currently do not support any management, but
we are working on a few that we have enough info to make some management
raid(4) however allows full management. For
simple mirroring or striping,
ccd(4) provides even better
performance, although it lacks some basic management knobs that I hope to fix
A lot of companies have been using OpenSSH in their products (Sun Microsystems, Cisco, Apple, GNU/Linux vendors, etc.). Did they give anything back, like donations or hardware?
Henning Brauer: Nobody ever gave us anything back. A plethora of vendors ship OpenSSH--commercial Unix vendors (basically all of them), all of the Linux distributors, and lots of hardware vendors (like HP in their switches)--but none of them seem to care; none of them ever gave us anything back. All of them should very well know that quality software doesn't "just happen," but needs some funding. Yet, they don't help at all.
This release includes the new OpenSSH 4.1. What's new?
Damien Miller: 4.1 is just a bugfix release; it didn't include any new features over 4.0. The new features in 4.0 included:
- Extending port forwarding to allow it to bind to a user-selected address rather than just localhost or the wildcard address. This turned out to be a fair bit of work and discussion to ensure that we didn't break backwards compatibility.
Added the ability to store hostnames added to ~/.ssh/known_hosts in a hashed format. This is a privacy feature that prevents a local attacker from learning other hosts that a user has accounts on from their known_hosts file.
So instead of hostnames being stored in plain text like:
> yourhost.example.com ssh-rsa AAAB3NzaC1yc2EAAAABIwAAAIEAp832eeMwYH...
They are hashed first, so they don't reveal the hostname. E.g.:
> |1|bRGYyrC+bfKZGGd5GZH4wo1AnsI=|xcQ+54QNVwQ+fBCldn0= ssh-rsa AAA...
We added at the request of some MIT researchers who found that a substantial number of user private keys on shared systems are not encrypted (a really dumb thing to do, BTW). This lack of user care, coupled with the information in the known_hosts files, allowed attackers to spread their attacks to multiple systems.
Right now this is disabled by default, but administrators of sites with lazy users can turn it on with the
If you do this, you should probably also hash your existing known_hosts file (
- Because the hostname hashing makes it more difficult to manually manage
known_hosts files, we added some tools to
ssh-keygento perform common operations, like finding listings for hosts and deleting hosts. These work on hashed as well as plain known_hosts files.
- More improvements to the
sftpclient. In particular, it now has basic command-line editing and history (no tab-completion yet, though).
- As usual, lots of other improvements and bugfixes :)
ntpd include any new features?
ntpd is not about features.
ntpd is about solving a relatively simple task the right way.
ntpd is about keeping the local machine's clock synchronized with
ntp servers, no more and no less than that. A plethora of little buttons
and statistics and query tools doesn't gain the majority anything, but imposes
a cost--more complex configuration, and more (potentially buggy) code. Our
ntpd is different. It is supposed to stay small and solve the
The only bigger new feature is the
-s option, which allows
ntpd to set the machine's clock hard on boot, so it is no longer
required (or even desirable) to run
I read some complaints about its limited precision. Is this a real problem for most users?
Henning Brauer: No, not at all. It reaches offsets of way below 100ms, typically below 50ms. That is about the clock resolution typical PC hardware reaches. None of the people crying for "better" resolution could ever give any valid reason why they'd need it--in fact, almost all couldn't give any at all.
I read that OpenBSD added the support for PIM (Protocol Independent Multicast). What is it? When is it useful?
Damien Miller: These changes came from FreeBSD and NetBSD via Pavlin Radoslavov and Ryan McBride. It is the kernel support required to implement the PIM multicast routing protocols (PIM sparse-mode and PIM dense-mode). These are the most popular ways to route multicast traffic between networks.
Note that OpenBSD doesn't have PIM-SM or PIM-DM daemons that can use this support in the base OS, but you can use Xorp from ports.
Claudio Jeker: PIM replaces the traditional multicast
mrouted or MOSPF to do multicast routing for a
certain area/network. In most cases, group members are sparsely distributed over
this area and protocols like MOSPF are very inefficient in these cases. PIM
introduces two new routing protocols, PIM-SM (Protocol Independent Multicast--Sparse Mode) and PIM-DM (Protocol Independent Multicast--Dense Mode).
Both protocols share the same packet format but the underlying concepts are
xorp (from the ports tree) has support for PIM-SM
on OpenBSD, but I don't know how usable it is.
PIM makes only sense in larger networks that need to do a lot of multicasting. A possible example are some IP TV solutions that stream every channel as its own multicast group. This reduces the network load on the backbone, but the end user is still capable of switching quickly between channels.
OpenBSD 3.7 includes in-kernel PPPoE support. Previous versions already have a PPPoE implementation in userland; why is there a kernel-based one now, too?
Can Erkin Acar: PPP is a protocol for establishing
point-to-point links. It is a quite complicated protocol with many options for
authentication, encryption, and compression. The existing userland
ppp(8) program supports a wide variety of these options and has
been in the tree for a long time. PPPoE (PPP over Ethernet) is a method for
establishing point-to-point links over Ethernet via PPP. Many ISPs provide
broadband services through PPPoE. The userland
pppoe(8) program is
used for establishing PPPoE links through
The main problem with userland PPP/PPPoE processing is the overhead. A single packet has to travel quite a number of times between the kernel and the userland before finally reaching the TCP/IP stack in the kernel. While not really noticeable with slow links, high-speed PPPoE links may increase the CPU utilization and the throughput may be affected.
When the PPPoE processing is moved to the kernel, much of the overhead is
removed. However, the PPP layer inside of the kernel (the
sppp layer) supports only a
minimal subset of the PPP protocol. While it is usually enough for connecting
to your ADSL link to your ISP, most of the other bells and whistles are not
OpenBSD's PPPoE (PPP over Ethernet) code is initially ported from NetBSD by
David Berghoff. It was developed and tested outside of the tree until one of the
developers (me) had enough time and motivation (Theo) to put it into the tree.
I modified the initial port to work with our
sppp layer, and moved the
functionality of the
pppoectl tool into
I continue to work on and improve the
sppp layer, which is also shared by the
Claudio Jeker: The userland PPPoE is a bit tricky insofar
as it uses
bpf to capture the PPPoE packets from the interface. This was a bit
ugly, as it needs root privileges to use
bpf, but since 3.6 PPPoE drops
privileges to user
chroots after setting the write
filters and locking its
bpf descriptor. The in-kernel version of PPPoE accesses
the device in a more natural way and has less overhead--the userland PPPoE
runs two processes and has to pass all data between the two processes and the
kernel. In some cases, it is still better to use the userland PPPoE because
its PPP back end is far more complete than
sppp(4) of the
The 3.7 release page shows some new PF features. How does each one work?
carpdevmode for IP-less interfaces.
Henning Brauer: Previously, CARP relied on the physical interface having an IP address in the same subnet as the
carpinterface. Now you can leave the physical interface IP-less, by specifying it when configuring the
# ifconfig carp0 10.0.0.1 netmask 255.255.255.0 vhid 1 pass XXX carpdev sk0
Support limiting TCP connections by establishment rate, automatically adding flooding IP addresses to tables and flushing states (
Henning Brauer: This was made to fight (D)DoS attacks. Basically, IPs with unusual high connection rates are detected, and added to a table. You can then block them based on that table, or assign them to a very slow queue or similar. It is also possible to flush all existing states from that IP when it gets added to the table.
Improved functionality of tags (tag and tagged for translation rules, tagging of all packets matching state entries).
Henning Brauer: Previously, we only tagged the first packet of a stateful connection, so that you had to filter statefully. We now tag all packets.
Improved diagnostics (error messages and additional counters from
Henning Brauer: Some error messages have been made more clear, and some counters were a bit overloaded, so we spread some off. This allows for a finer view on what
pfis doing now.
New keyword set skip on to skip filtering on arbitrary interfaces, like loopback.
Henning Brauer: It does exactly that--"disable"
pfon the given interface(s).
Henning Brauer: It is now possible to assign labels to routes--basically, 32 bytes of arbitrary information that can be used for almost anything. For example,
bgpdcould record information about the source AS number for that route, or about the peer it learned the route from.
pfcan then filter based on this information--or apply queuing :)
bgpdcannot set these labels yet, but that's the plan.
What is new in the IPsec/
Hans-Joerg Hoexer: For 3.7, we mainly focused on stability
and interoperability: the implementations of the NAT-traversal (NAT-T) and
dead-peer-detection (DPD) features that we shipped with 3.6 were not mature
enough. These issues have been resolved for 3.7. Among many minor bugfixes, we
also made sure that it is possible to run multiple instances of
isakmpd on different ports again.
Ryan McBride added a nice feature for typical roadwarrior setups:
in addition to IP addresses, isakmpd.conf now also understands
interface names and the special keyword
default, which selects the address
based on the default route. Thus one does not have to change isakmpd.conf
when the interface address is assigned dynamically.
Did you develop any new feature to fight spam?
Bob Beck: Yes, I've added a "greytrapping" feature to
spamd. This allows a site runner, when greylisting, to make use of
old unused email addresses (or any other ones that spammers like) as spamtraps
for the greylist. This is done by adding the spamtrap address to
spamd's database with the
spamdb(8) utility. After
spamdb -T -a "<firstname.lastname@example.org>"
if a server is running doing greylisting, any greylisted host who attempts
to mail to the destination address of
would be blacklisted for 24 hours. These machines then show up in the
spamd database as
TRAPPED entries for the next 24
spamdb -a | grep TRAPPED ... TRAPPED|126.96.36.199|1113143172 TRAPPED|188.8.131.52|1113148919 TRAPPED|184.108.40.206|1113159698 TRAPPED|220.127.116.11|1113158993 ...
The spamtrap address has no effect on established
servers; i.e., mail servers I regularly correspond with could mail to
email@example.com without being trapped. This only affects hosts
that are a candidate for greylisting; i.e., I haven't exchanged any mail with
them at all (or recently).
Good candidates are any unused address or formerly used address that has
been harvested or appears in a public forum. (in fact, you can pretty much
count on my putting
firstname.lastname@example.org into my spamtrap list
before I even see this article, since spammers like to harvest anything that
looks like an email address to a resolvable domain :)
I have small servers consistently running several hundred
TRAPPED entries, and large ones running
fluctuating between 7000 and 10000 entries. These seem to pick up more hosts to
blacklist than the typical spews and spamhaus lists, without any side
This is the first of several new features to take advantage of the 30-minute
initial delay given by greylisting, as spammers seem to be noticing. Noticing
is good. This means both that it works, and that spammers are easier to identify if they
don't like talking to
running readers try the following in their
define('confSMTP_LOGIN_MSG', '$j spamd IP-based SPAM blocker; $d')dnl
Reading the changelog I found a funny point: "The Great Apache Cleanup of 2004 to remove code we don't use." What is the status of the forked Apache included in OpenBSD?
Henning Brauer: Well, we're cleaning up the mess, starting by removing code we don't use. In the end, we hopefully have readable code, and we're pretty sure we will fix security bugs in the process.
Since the Apache people decided to change their license to an un-free one, we cannot import newer versions anyway--which is not really a loss, given that they don't really put any work into the 1.3 tree any more. Our Apache has hundreds of fixes they didn't take back even before the licensing issue. Now it has even more, and they still don't have them. We're fixing more stuff on the way, most often without noticing--we are just fixing bugs.
So, technically, this could be called a fork.
This is the first release that includes X.Org. Why did you choose to import it instead of XFree86 4.5.0?
Matthieu Herrb: The primary reason is that the new revision 1.1 of the XFree86 license is less free than the old MIT license that had been used for years by XFree86. OpenBSD already avoided shipping the final XFree86 4.4 release that also uses the new license in 3.6. Then, as many other projects moved away from XFree86 because of the license, it became obvious that most new developments in the X window system now take place in X.Org. Having said that, projects like OpenBSD have to stay vigilant that X.Org doesn't turn into a Linux-only project (that would slowly slip to a GNU General Public License).
What new features do package tools support?
Marc Espie: A lot!
The most visible new feature is probably the progress meter. If you add/remove packages, you will now get instant feedback that something is going on. A related features is that the message system has been completely redesigned to be more useful: it's much harder to miss things now.
In general, the system is more robust, handles more fringe cases better, and is a wee little bit faster. Package tools in 3.7 consume half the memory they did in 3.6.
Shared library handling has been totally rethought. Packages will now check that libraries in the base system are present, with the correct version. And also register and handle inter-package library dependencies fully. From the ports people point of view, it's now much easier to write correct package dependencies than it ever was.
The object-oriented packing-list framework has been cleaned up, and is now used extensively through the whole package system. This is a huge improvement, because some very nice tricks are now feasible with a few lines of Perl. For instance:
- Packing-lists updates are now 99 percent automatic and correct.
- There's a new
pkg_mklocatedbtool that you can use to build a small
locate(1)database of files all packages can install. It took about half an hour to write with the new tools.
Alongside shared libraries, the package system now includes smart ways to handle:
- Man pages
- Texinfo files
- Configuration files
And I've probably forgotten a few things along the way. This means that
most special cases (
INSTALL) are gone. In most cases, you just say "OK, this file is
man page" and the system will do the right thing. (Heck,
make update-plist will often do the guessing correctly for you.)
For instance, one minor thing you'll notice is the instant update of the
This is way more robust than the old tools. A lots of simple manual mistakes in making ports with the old tools will just not happen with the new ones.
OK, I've kept the big one for last.
You can use
pkg_add -r foo-1.1 to replace your old
foo-1.0 package with the new
That's right, we've got a real update system.
pkg_add -r will
(more or less):
- Unpack the new package near its final install place.
- Check that dependencies still match (both forward and backward).
- Check that the deinstall of the old package will work.
- Check that the install of the new package will work.
- Proceed with the deinstall.
- Finish the install.
- Adjust dependencies for the new package.
Yes, Virginia, you no longer have to uninstall the old packages before
installing the new ones.
pkg_add -r will deal with dependencies
correctly. For instance, assume you want to update
xv. You know
it depends on
So you just have to:
pkg_add -r <newjpeg-pkg> <newpng-pkg> <newtiff-pkg> <newxv-pkg>
and it will just work, by first updating
tiff, and finally
It handles shared libraries correctly, keeping old libraries around until all packages that need them are updated, and is generally pretty safe.
What is the roadmap for their development?
Marc Espie: Next on my list is handling really complicated update cases, where you can't update packages individually (for instance, when files move from package to package, you have to update both packages at once).
There's also some redesign for dependencies (again) to take updates into account.
And there's a smarter tool to do updates too. If you read
-r's description, you'll notice that you have to specify all of the
packages you want to add. The counterpart would be a
where you just say "OK, I want to update those packages, so locate the
replacements, and just do it." We're getting there.
As usual, there's some quality-assurance work to do. Even though
pkg_add -r has seen a lot of testing internally, I'm certain there
will be a minor quirk or two to take care of after the release.
The next very significant change will probably be in the ports tree itself.
A lot of the
pkg_tools replacement effort was geared at ensuring
better quality of the ports tree. Well, this is now mostly done. Porting
software has gotten simpler. A lot of mistakes no longer happen. So the
remaining mistakes are, of course, more visible, and need to be taken care
One important policy you'll already see is that we're much more careful in bumping package names each time we change anything--having update capabilities mean people will want updates to work. And they will mix and match packages from various points in time, even though this is not guaranteed to work. Between very precise package names, and the registration of shared libraries versions, the package system is doing its best to "get out of the way" and ensure things will just work, or say in a very obvious way, "Hu, hu, no, sorry, you really shouldn't do that" if the user does a stupid mistake.
I saw various updates for
mac68k. This is not a modern
platform, so what happened?
Martin Reindl: As you noted, pretty much.
mac68k was rotting away for quite some years. The hardware is
quite slow and there is no fancy stuff like USB or wireless. Nevertheless, the
exotic hardware nature is a valuable proving ground for the kernel APIs and
OpenBSD in general. A nice example how
mac68k helped showing bugs was a fix to
CFLAGS could be set with
system wide for all architectures.
It all started in fall 2004 when I dusted off a stray NuBus network card. It
was not recognized back then, but the fix was easy. Miod Vallat then contacted
me, gently pushed me in the right directions, and gave me some good information
on where and how to start working if
mac68k support should not be dropped. So I
started merging code from NetBSD and after two weeks I had quite a big
covering a new interrupt system, much more like the one in the
hp300 port, and
a much more flexible serial driver. This in turn allowed Miod to add
Things took off and Claudio Jeker fixed the
mc(4) driver as
found on the fastest
mac68k, the 840AV. Another long-standing bug was fixed by
Miod, which made it possible switching to bsd.rd as the preferred install
method. (Cutting down the install time from like one day to one hour!) With
this came the ability to finally use more than one disk. Various other
subsystems were also improved, including the driver for the Quadra's onboard
SCSI controller, resulting in much better disk performance (which is
weak point). During all of this time Nick Holland, Otto Moerbeek and many other
developers provided rich testing reports and help.
So what we have now is a
mac68k port that runs better than ever on Quadra
machines, including new support for the AV machines. Projects for the future
include improved NuBus support,
pdisk, as well as many small
bugfixes and code merging.
I think people will get excited by the Zaurus port, bringing a secure SSH-capable machine to their pocket. What is the development status?
David Gwynne: It is trivial to find an OpenSSH package and install it on the Zaurus's default Linux distribution. I believe the availability of these packages is a good demonstration of the effectiveness of the work that the portable OpenSSH guys are doing.
Personally, I am more interested in having OpenBSD itself and some of its
other features on a wireless device in my pocket. Being able to build a
temporary access point out of a Zaurus with a USB Ethernet device and a
wireless CF card and using four commands to set it up is extremely cool. Apart
from my own needs, I know that people want OpenBSD on the Zaurus for the same
reason they want it on
macppc; they want to use something
they trust and are comfortable with.
The 3.7 release on the Zaurus C3000 is surprisingly usable considering the short amount of time it has actually been in-tree. It is a functional system with exactly the same software and ports tree as found on any other architecture OpenBSD runs on. As for Zaurus hardware, 3.7 ships with support for its display, keyboard, touchscreen, Compact Flash slot, and the USB controller. This means that if your USB device works on your desktop or laptop, you can expect it to work on the Zaurus. The same goes for Compact Flash devices.
Development is already progressing post-3.7. Power management is constantly being improved, mostly thanks to Uwe Stuehler. Drivers for the rest of the onboard Zaurus hardware are being written. For example, Chris Pascoe has already provided a basic driver for the sound hardware. The Zaurus has become a popular toy among the developers, so there is a lot of interest in producing good device support.
Are there any particular limitations?
David Gwynne: In my opinion the biggest limitation is the need to keep Linux on the device; it is only used as a glorified boot loader for OpenBSD itself. I would love to see OpenBSD boot up when I press the power button instead of Linux.
Uwe Stuehler: A minimal fraction of Linux must remain on internal flash memory in order to run OpenBSD's boot loader. Those who want to use the whole disk for OpenBSD can do that, assuming they can do well without the applications that ship with the Zaurus.
The boot loader is mostly the same as on other OpenBSD platforms. It is conveniently installable via the same package installer that you would use to install OpenSSH on Linux. Once it is installed, OpenBSD can indeed start immediately every time you press the power button or reboot the Zaurus.
There are intrinsic limitations of the ARM processor being used in the
Zaurus, such as the lack of a hardware floating-point unit. Our ports tree already
contains alternative software that is better optimized for integer arithmetic
mpg321 as an alternative to
gaps currently remain can hopefully be closed as more developers port their
software to various ARM platforms.
Is there any plan to support other devices beyond the Sharp Zaurus SL-C3000?
David Gwynne: The Zaurus port originally started out on the SL-C860, but was quickly moved to the C3000 due to the better onboard hardware. The intention has always been to go back and make OpenBSD work on the C860 once we're happy with our work on the C3000. In the short term, it might be easy to support the new C1000, since it is basically a C3000 without a hard disk. Support for other Zaurus handhelds should be fairly trivial once the C860 and C3000 are both working, since the same devices and CPUs on these handhelds are used on other models, too.
Uwe Stuehler: Despite there being certainly at least a little bit of interest, I think realistically nothing much apart from recent Zaurus models has a chance to be supported anytime soon.
This release introduce
gcc 3.3.5 for common platforms
macppc. What pros/cons does this version of
gcc bring over the old and patched
Marc Espie: Obvious con:
gcc 3.3 is about 30 percent slower than
Pros: a lot of modern C++ code now compiles. There's no way to avoid recent
gcc for some architectures, like AMD64. The various language parsers now give
much better diagnostics. In particular, the new C preprocessor is very
Do you plan to update to
gcc 3.4 or 4.0 in the near
Marc Espie: Nope.
gcc 3.4 adds a whole set of C++ problems
we don't want to deal with right now (more stringent syntax, catastrophic
memory increases in some cases), and
gcc 4.0 is definitely not mature
technology yet, and it's even slower than
In a previous interview I did with Richard
Stallman, he stated that
gcc will include ProPolice. I hope
this is this good news for you. Is there any other technology that you would
like to see imported into
Marc Espie: OK, this might be the scoop you're looking for.
This is not news to me. This is definitely not good news. In this instance, Richard was all talk, and no action. There is absolutely nothing going on that indicates that ProPolice will be a part of future GCC releases.
Let me publicize that more. The GCC people are going to say they haven't had any luck collaborating with Etoh Hiroaki.
I've inquired into the problem, I've offered to help by acting as liaison between the GCC developers and Etoh Hiroaki. I got a lukewarm response at best.
Right now, the ProPolice technology is not considered stable enough for inclusion in GCC. Technically, the stuff Etoh does is a nice hack that plays interesting games with GCC internals. Those games are actually not really supported inside of GCC. (ProPolice assumes the frames have a given internal representation, which is 99 percent the case in practice, but is not part of the GCC internals' contract.)
And this is it--this is as far as ProPolice integration so far has gone. Richard asked for ProPolice to be integrated, which does not cost him anything. It's just a PR move, as far as I'm concerned. No resources have been devoted in actually pushing for ProPolice to be integrated.
The GCC people are handling other stuff, which is more important for them, which is something I quite understand.
There is absolutely nothing going on where ProPolice integration is concerned.
Yes, there's a lot of work. Ask the OpenBSD developers how many issues we
had to solve in
gcc in taking ProPolice from the "proof of concept" stage to
"integrated compiler technology in the
gcc we ship." Hundreds of hours. Sweat
Well, right now, ProPolice stops at GCC 3.4. No one has a working ProPolice for GCC 4.0. No one is devoting enough resources to ensure this will happen. And you think we will switch to GCC 4.0? Think again.
Instead, GCC 4.0 will ship with a framework called
mudflap, which does about
as much as "flap, flap, flap" flying through code. It catches one valid bound
violation every April the 1st, and complains about valid code every other day
of the year.
No ProPolice in sight.
Federico Biancuzzi is a freelance interviewer. His interviews appeared on publications such as ONLamp.com, LinuxDevCenter.com, SecurityFocus.com, NewsForge.com, Linux.com, TheRegister.co.uk, ArsTechnica.com, the Polish print magazine BSD Magazine, and the Italian print magazine Linux&C.
Return to the BSD DevCenter.