FB:There is a new driver called iic(4)
for Inter IC (I2C) master/slave buses. I've already heard that acronym, but I'm
wondering, what is it exactly?

Alexander Yurchenko: I2C (I square C)--Inter Integrated Circuits--is a two-wire bus originally developed by Philips; [it is now the industry] standard now for connecting simple devices such as sensors, EEPROMs,
tuners, and so on. It's cheap, simple, has hot-plugging ability by design. I2C
is very common in the embedded world. On usual PCs, I2C is often used for connecting
hardware-monitoring sensors to the CPU or for controlling video and radio
receivers.

iic(4) kernel framework was written by Steve C. Woodford and
Jason R. Thorpe for NetBSD, and I've ported it to OpenBSD. It provides a uniform
programming interface layer between I2C master controllers and various I2C
slave devices.

FB:What type of devices use it?

Alexander Yurchenko: For now we support only one master
controller and one slave thermal sensor, both found on the WRAP x86 board.

FB:gpio(4) supports General Purpose
Input/Output controllers, while gpioctl(8) can manipulate device
pins. Is this interface available on common hardware?

Alexander Yurchenko: GPIO, like I2C, also came from the
embedded world. Though GPIO controllers are integrated now in many popular PC
chipsets, they're not used. You could find GPIO pins on the single-board
computers like Soekris or WRAP. ARM- or PPC-based system-on-chip devices also
have integrated GPIO controllers.

A gpio(4) framework allows you to manipulate pins either from
userland or from kernel. For example, you can connect a red LED to a GPIO pin
and switch it on if something's wrong with your system.

FB:This release ships with the driver for
AIC79xx-based Ultra320 SCSI adapters. Is this the first Ultra320 SCSI
driver?

Marco Peereboom: No, and to my knowledge there are
currently only two U320 SCSI offerings. One from Adaptec and one from LSI. All
other offerings that use U320 are based on either chip.

OpenBSD supported firstly the LSI-based 53c1020/1030 U320 chip with the
mpt(4) driver. This chip is used on a plethora of servers from
different vendors. With the introduction of the chip, we also started supporting
LSI megaraid-based RAID cards like the Dell PERC 4/DC and SC that use the
ami(4) driver.

Before we introduced the Adaptec ahd(4) driver, we actually
supported Adaptec's U320 RAID cards. These were aac(4) based and
therefore easy to add to the list.

The glaring thing that is missing on this list is LSI's IM/IS/IME extensions
to the 53c1020/1030 chip. These are RAID 1 (Integrated Mirroring + Enhanced)
and RAID 0 (Integrated Striping) that can be provided using the 53c1020/1030
chips that have the required peripheral hardware (EEPROM). I am actually
working on adding support for this, but I am unsure when it'll be ready.

FB:Would you suggest to buy U320 hardware or U160 for
an OpenBSD-3.6 server?

Marco Peereboom: Absolutely! Nothing beats compiling a
kernel on a bunch of SCSI drives. SCSI is considered higher end than PATA/SATA, the difference being that PATA/SATA are pushing technology for density and
speed. As with any technology that is pushing its limits, it is inherently less
reliable. The technology that proves to be most reliable is then reused in
SCSI drives. The PATA/SATA technology however uses a considerably simpler bus
and has nowhere near the same amount of intelligence. SCSI is more reliable and faster because "all" complexities are offloaded to the physical devices.
This is important because the OS therefore does not need to waste any time
dealing with the underlying protocol. Currently PATA/SATA drives are creeping
up into the SCSI domain by providing SCSI-like technologies such as tagged
queuing. Problem is that these are vendor specific and not defined in a spec
that is widely available. Because of this, most OSes are not using these devices
to their full potential.

A common misconception between SCSI and PATA/SATA is that people will note
that sometimes the latter seems faster. What really is happening is cache
trickery. Since PATA/SATA is ended toward home users, vendors turn on all the
caching that they have on those drives to wring out every bit of performance.
The SCSI products, on the other hand, are ended toward enterprise customers who
value data integrity over speed, so they disable all cache on these drives to
prevent data loss/corruption. Both types have utilities or mode pages to change
this behavior for specific needs; choose wisely.

U320 devices are over the hump; as with all new technologies it takes a
while to remove the final kinks, and U320 gear is nowadays as stable as the
slower U160 counterparts.

I personally only use SCSI on production boxes, the only exception being
firewalls that basically have no I/O load at all.

FB:Which adapters in particular?

Marco Peereboom: I am a sucker for the LSI U320 gear. The
reason for this that mpt (message-passing technology) basically is a generic
transport mechanism that can be used for a wide variety of devices. With
minimal changes an mpt-based driver can be adapted to add support for GigE,
iSCSI, FC, and SCSI, our driver currently supports FC and SCSI. The mpt spec
can and is being scaled beyond these devices. Besides this generic interface
for a bunch of gear, mpt also offloads all the protocol specifics in hardware.
This is really cool! The driver sends of an I/O, and a while later it gets an
interrupt telling it if the I/O completed or failed, and based on that it will
send it back to the SCSI midlayer. In other words, the driver has a very small
footprint and is extremely simple and fast.

All this said, I want to thank LSI for all the hardware and documentation
they donated to OpenBSD. I got a lot of good suggestions from their engineers
on particulars of the chip.

I also want to thank Adaptec, who donated quite a few boards to OpenBSD. They
did, however, not provide us with documentation and pointed us to the FreeBSD
driver as their documentation. In all fairness, Justin Gibbs from Adaptec and FreeBSD did answer all questions promptly.

And I want to make sure that credit is given where due. I codeveloped these
goodies with two brilliant guys, Kenneth R. Westerback and Milos Urbanek.

FB:This release supports a new platform. Since I don't
own any LUNA-88k box, I'm wondering what type of things you can do with OpenBSD
3.6 on it (workstation, firewall, server, ...).

Kenji Aoyama: Well, at this moment, I am using my box just
for "fun"; i.e., porting OpenBSD itself. But OpenBSD/LUNA-88k becomes relatively
stable now, I would like to use it as a server in my home network.

FB:I've read that there are still some unsupported
devices and features like SMP. Are you looking for any particular help from the
community (hardware, money, resources, ...)?

Kenji Aoyama: It would be nice if I got an original working
LUNA-88K box, not LUNA-88K2 that I already own. They have some difference in
peripheral devices, so it makes better LUNA-88K support. In addition, if I have
two boxes, I can develop on one box and build a snapshot on the other box at the
same time. It takes three days to build a snapshot on LUNA-88K.

FB:OpenBSD is probably the BSD project with the best
support for Apple's hardware. What type of contributions is Apple sharing with
you?

Dale Rahn: Basically, none. I talked with Apple's open
source representative at USENIX 2001 and USENIX 2002 but was unable to obtain
anything useful. After USENIX 2002, the APSL was modified to make the code
somewhat more free; however, OpenBSD developers still avoided using it as a
source of information to avoid APSL contamination. It had not been a free license. Recently this has improved with APSL 2.0; it is now more GPL-like, which is slightly more but not completely free. Note that OpenBSD has removed
GPL code where is was possible; there is no GPL code in the kernel, for instance.

FB:Have you obtained all the docs and specs you
needed?

Dale Rahn: I have obtained no documentation to assist with
the effort. Most of the development is based on NetBSD or Linux code. Most of
the improvements have been the result of dedicated developers trying to make
their macppc laptops run nicely. While greatly outnumbered by i386 laptops, a
significant number of developers were using macppc laptops at the last
hackathon.

FB:Is Darwin/OpenDarwin a good resource for code
sharing?

Dale Rahn: Because the APSL has not been a free license,
this resource is normally avoided. Sometimes it has been used as a reference
when the Linux code was not clear.

FB:Has Apple showed any worry or interest about the
OpenBSD porting to the PowerPC platform?

Dale Rahn: I have never been contacted by Apple. The fact
that Apple ships OpenSSH with MacOS shows that they know that OpenBSD exists,
but they appear to not have acknowledged that OpenBSD/macppc exists.

FB:ethereal was removed from the ports tree because
"the ethereal team does not care about security, as new protocols get added,
and nothing gets done about the many more holes that exist." I hope that this
is not the beginning of a hunting season to remove software because it's [insecure. That] will end with a system that's secure because [it] can't do
anything. I'm wrong, right?

Peter Valchev: You are in part correct.

People often forget the main purpose of the ports tree is to provide
packages, especially on the CDs when a release is done, for convenience. When a
piece of networking software running with root privileges continuously gets
holed, and the developers do not address the root of the problem (the big hunk
of code running as root), the other facts aside, means we ship a holed version
in our releases. Then many people, not knowing better, will just add the package
in question and get in trouble. Namely, that was the case in 3.5. This kind of
software does not belong to the ports tree for mainly that reason ... especially
when alternatives exist. And maybe someone who cares about this particular
piece of software and relies on parts of it can use this as motivation and
address the root problem. You are not wrong that OpenBSD will discourage the use of
insecure software in the future, in the ports tree or not. It's why rlogin was
removed from the source tree, for example. I know of a big institution that
recommends rlogin over ssh to this day. I don't think that is the world OpenBSD
enthusiasts want to live in.

FB:How does the port team interact with ported
software developers? Do you submit any patch for OpenBSD portability or to
improve the security of their projects?

Peter Valchev: The main job of a port maintainer is to
interact with the upstream author/maintainer of the software. The goal is to
submit all patches and solve portability or security/other problems, and
usually the authors are very helpful and consensus is reached, with these
changes making it into the new releases. Of course there are exceptions, as
well as abandoned or "dead" projects, so the ports tree will always be full of
patches maintained by us.

FB:On the misc@ mailing list there were
some discussions about Apache and the version in the OpenBSD source tree. It
seems that you chose to fork from version 1.3.29 and then introduced a lot of
fixes, some of them security related. This sounds good to me, but do you think
that keeping the name "Apache" is judicious?

Henning Brauer: No, this is completely backward. We did
NOT fork from 1.3.29 and then did a lot of security fixes. We always had a
number of security fixes, mostly in mod_ssl. Some releases ago I wrote the
chroot extension. We did more fixes over time, as we found more problems. Of
course, we always notified people in the Apache team, but they apparently
decided to not care, or in some cases to ignore problems because they could not
solve them on some obscure platforms that don't have [reasonable sources of] randomness. So yeah, good idea, let everyone suffer because one or two platforms
can't get it right. If there was proof needed that it is impossible to write
reasonable code for both Unix and completely non-Unixy platforms, they made
it.

So by now the diff between our in-tree Apache and their 1.3.29 is well
beyond 4,000 lines.

After the 1.3.29 they decided to muck with their license, introducing stupid
patent terms without understanding what they turned their license (that used to
be a BSD-derived one) into with that, so we cannot import new versions unless
they fix their license. It is not a big loss tho'. The Apache people have
mostly given up on 1.3 anyway, and all that happened over the last years was
bug fixes, documention work (actually, mainly translation), and some stupid code
shuffling, that only made diffs bigger without improving anything. Now that it
is certain that we don't have to worry about syncing to them any more, we can
start making the mess of code readable tho'. That is, unifdefing,
replacing all those ap_something function calls by their native
counterparts (e.g., ap_snprintf -> snprintf), and
such. I am pretty certain that there will be bugs discovered or "accidentally"
fixed in that process. It is a lot of work and I cannot do it all by myself,
but I hope to get help.

FB:If I'm not wrong, this release doesn't add any new
feature to spamd. Isn't there any new idea to fight spam that you
would like to add to spamd?

Bob Beck: Nope, no new spamd features in 3.6.
The work I've done post-3.5 has been in other areas. I had a few grand plans,
which were mostly put on hold by a big flood we had in my hometown (Edmonton,
Alberta). It backed up raw sewage into my basement, forcing me to tear down my
entire computer room and store all my machines in piles upstairs. (This was my
computer room on July 16.) Since when this happens there are no contractors
available to do any work for you, I've had to do it all myself/bug friends
to help, and rack my credit cards up to pay for it. I'm still waiting for my
insurance company to give me a dime so I can pay the bills and replace some of
the furniture I lost. (Let's just say I have a special place in my heart for
Meloche Monex Insurance, right next to the place for all the spammers.) I'm just
now getting back to where I'm not spending every free minute doing forced
renovations, and I can have fun again.

I'm currently most interested in making it possible to distribute the spamd
database in a couple of ways for post-3.6. This is important so people running
multiple MXes can still make use of greylisting properly.

I'd like to look at adding features to spamd that make it
possible to more effectively share information between or from trusted sites,
particularly the whitelist information, which is actually the powerful stuff. I
think there's also room in spamd to allow for spamtraplike
functionality from the greylist, and I will be looking at getting a clean
implementation of that in.

There are many other spam-fighting possibilities that do *not* belong in
spamd; it's important to keep that in mind. If it's better done in
the MTA, then that's the place to do it. I do like keeping spamd
small, simple, low impact, and secure.