AddThis Social Bookmark Button

Print

OpenBSD 3.6 Live
Pages: 1, 2, 3

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.

Pages: 1, 2, 3

Next Pagearrow