Platforms & Management
How does FreeBSD 7.0 handle virtualization? Would you still suggest to use Jail, or is virtualizing the whole OS better?
Alexander Leidinger: Work is underway to get FreeBSD running as a guest in XEN (will not be part of 7.0, but if it is ready it could be part of 7.1 or 7.2 or 7.x).
Running FreeBSD in vmware/quemu/... is possible (not only with 7.0).
Using a jail or virtualization is not a "the one or the other"-question. It depends on your usage scenario. So yes, we (still) suggest to use jails, but there are also valid used for virtualization (be this running FreeBSD in vmware/qemu/... or in hardware assisted XEN).
How do you handle power management?
Nate Lawson: ACPI in FreeBSD 7.0 has been mostly an incremental improvement over 6.x. We've updated the ACPI-CA layer to fix various compatibility problems with non-standard BIOS. Cpufreq support has been available since 6.x but it is now enabled by default. The automatic management of CPU frequency (through powerd(8)) is also the same as 6.x. Internal work now allows rc.suspend and rc.resume to run to completion before the kernel suspends, similar to apmd(8). Most of the work has been on trying to fix bugs and increase stability.
You can see the man page for CPUfreq(4) to see the list of speedstep and all features that are supported. 6.x and 7.x are equivalent I believe.
Why have you added FireWire support to the boot loader?
Hidetoshi Shimokawa: FireWire support in the boot loader is limited to dcons(8) that is for kernel debugging. Unfortunately, it does not support sbp(8) (SCSI over FireWire) nor fwip(8) (IP over FireWire) to boot FreeBSD over them.
Dcons(8) exploits Remote DMA feature of FireWire OHCI (fwohci(8)) and provides a very convenient way for kernel debugging compared with legacy serial console.
As a kernel developer or system administrator, we sometimes need to interact with loader or kernel in very early stage of boot process over serial console or dcons(8). This is why I added FireWire support in loader(8).
If you would like to try kernel debugging using dcons(8) see the wiki page.
It is very useful for laptops without serial ports. Dcons(8) support in loader is limited to i386 and amd64 platforms.
What difficulties did you have to overcome to support legacy-free hardware (e.g. MacBook Pro)?
Rui Paulo: Legacy-free means running an operating system using the new "standards", i.e. the old keyboard controller is gone, BIOS is replaced by EFI, ACPI is now required and all basic peripherals are now USB.
First of all, FreeBSD is not yet legacy-free on the amd64/i386 architectures. We still run on MacBooks using the BIOS. There's preliminary support for EFI on i386. We still have one or two problems left regarding to the USB keyboard and the touchpad, but I'm confident we'll fix those in time. We had problems in the beginning regarding to how the hardware in the MacBooks is being initialized by the EFI, but I think we overcome those by now.
For testing, I used my first gen MacBook and asked on the mailing lists for more testers.
There's a wiki page about this project that I try to keep as up-to-date as possible.
Hi-def audio?! Did I hear correctly? :)
Alexander Leidinger: This is not only new in 7.0, it should also be available in 6.3 (also true for snd_emu10kx and snd_env24 and snd_anvy24ht). The new thing about sound in 7.0 is I think the internal improvements in the sound infrastructure. There was a lot of work from Ariff to get lower latency and less audible hickups. He also prepared the way for multi-channel audio. Multi-channel audio is not there yet, but the sound infrastructure is improved in a way so that implementing multi-channel audio is less work now.
A lot of people use FreeBSD as a server, so I think they will be very happy to hear that this release support IPMI (Intelligent Platform Management Interface) and monitoring system hardware. Would you like to tell us what features and hardware are supported?
Doug Ambrisko: My employer IronPort Systems needed a way to leverage the industry standard hardware reporting. Our servers had IPMI support. I looked at some existing projects like IPMItool, freeIPMI, Doug White's IPMI work and OpenBSD. IPMI stands for Intelligent Platform Management Interface. In simple terms it provides access to a microcontroller that can read temperature values, fan speed, report hardware events, log other system events including events from the OS, power control and in version 2.0 a industry standard to do SOL. SOL is Serial Over LAN. With this an IPMI complient tool like IPMItool can communication to the IPMI controller. The IPMI controller can be configured to be connected to an onboard serial port. Then you effectively have a built in terminal server.
So coming back to the start. I wanted to IPMI and leverage others people work as much as possible. There was a lot of people working on IPMItool and it you look around a lot of system vendors use it. It was modular with various interfaces. It didn't have a direct I/O interface but I think that is a good thing. FreeIPMI was a little hard to use at the time and didn't have some of the feature that IPMItool hard. OpenBSD had a built in interface which IMHO wouldn't leverage other people working on it as much as IPMItool or FreeIPMI.
One thing I've learnt when trying to get something on FreeBSD is to look to Linux and leverage them. So looking at IPMItool I figured out the minimum that I needed to do to provide and OpenIPMI compatible interface. It looked fairly straight forward so I worked at getting something to work. Having the kernel control access to the HW is important since you have to pass messages through a few I/O or memory addresses. If someone else starts banging on the same resources then you have corrupted messages. So the kernel ensures one thing is talking to the IPMI controller at one time. I think that in theory we could multiplex talking via the IPMB optional device. Once I got an OpenIPMI like interface working then we just had to teach IPMItool and FreeIPMI how to find that the driver is there.
The next part was to add the various more methods on how to talk to the IPMI controller. They can be KCS, SMIC, BT, and SSIF. KCS is the most popular. We support KCS, SMIC, and SSIF. Then there are the various methods that tell us how to talk to the IPMI controller. This itself can be describe via SMBIOS (which is related to DMI). Other methods include PCI attachment, ACPI and now hints file. I ran into server in which it had a IPMI controller but didn't have provide and locating services so we can manually specify in that case. Having all of the various attachments can make attachment tricky since it could be owned by ISA, ACPI, PCI or go through SMBUS (which is the onboard i2c interface). John Baldwin helped a lot in refactoring code, cleaning up some of my prototype hacks and adding his own. He got SSIF up and running. So Yahoo! helped a lot.
Once I got the base driver working then I started adding more features such as tying it into the watchdog kernel interface.
Fooling around with things is interesting. I made a simple port proxy to program so that I could attach GDB to a SOL session talking to the kernel gdb. Then I could do real remote debugging of a machine that was down a few floors only connected via a network.
Anything that is added to IPMItool or FreeIPMI we can use. There are some limitations though since I haven't implemented the event notifcation service. Still a lot of useful work is done by others that we can leverage by making a relatively simple driver.
Another advantage of the OpenIPMI like driver is that HW vendors can re-compile their binary tool to run on FreeBSD. I really should create a Linux ioctl shim but havn't needed to that. It would be really simple but I haven't got around to it.
There are some things the are in the wings such as IPMB support and sending panic information into the IPMI SEL (System Event Log). I also have some code to dump in an abbreviated kernel back trace. This can be useful if the disk dies and you can't core dump to a disk and are not watching the console for panic messages. Although these are nice to have features they are totally done yet but sample code could be made available to others to polish it off.
Again thanks to IronPort Systems and Yahoo! for working on the FreeBSD drivers. Obviously, we thank the people that work on IPMItool and FreeIPMI. Lastly we can't forget the people that got the OpenIPMI driver into Linux that we could emulate which made the other stuff just work on FreeBSD!
This release introduces a new platform: ARM. Not everyone has one of these boxes to play with, so could you tell us a bit of the features of the hardware and how FreeBSD can take advantage of them?
Olivier Houchard: Just to nitpick, technically the ARM port first appeared in RELENG_6 :) ARM is neat in that it's a simple and easy-to-understand processor. Unlike i386, each ARM CPU is very different, so supporting a new CPU is a bit of work, mainly device driver writing. It generally comes as a SoC, with a lot of devices embedded. you may find a PCI bus, an USB bus, an ethernet adapter, etc. Most of them are specialized, and I'm mostly interested in network and I/O CPUs, because that's an area where FreeBSD can shine. As for the performance work on 7.0, it had an impact on ARM, but not as big as other platforms, mainly because that work was essentially directed to improve SMP performances. There's SMP ARM hardware, but I wasn't able to get some yet :) I started the ARM port for no good reason :). I was looking for a "big" FreeBSD-related project, to learn more about FreeBSD internals, and adding support for a new platform seemed like a good choice at the time. I just picked ARM because it was the last big architecture nobody was working on with affordable hardware, and because NetBSD already supported it, so it would make the porting work easier.
Warner Losh: The ARM platform actually spans a wide range of potential devices. There are fast ARM processors that are used in things like SAN devices, network processing engines and the like. There are slower ARM devices that sip the power so are useful for applications where power usage is at a premium. These include battery powered devices as well as control systems where heat needs to be kept to a minimum. Given this wide range of devices, it is hard to comment more specifically.
I can comment on the ARM-based product that I helped bring to market. This product was the control processor for an advanced, flexible timing platform. This timing platform decoded signals from GPS and produced timing clocks and pulses that were aligned to the official UTC time standard. The processor booted off an SD card like you'd find in any digital camera today. We stored configuration information about the cards that were plugged in, as well as user settings, in I2C EEPROMs. We interfaced to the GPIO pins of the processor to detect cards arriving and departing, as well as for more mundane tasks like lighting LEDs. This project was based on the Atmel AT91RM9200 processor. Although it runs at only 180 MHz, we found FreeBSD to be quite responsive for the needs that we had. Our entire control program, complete with SNMP management interface, typically only used about 10-15% of the CPU.
Other ARM based devices, from vendors such as Intel, Broadcom, Marvell, Samsung, and Cirrus Logic are also supported, either by the mainline code, or by code that's in the experimental part of the FreeBSD on the glide path to being committed. These devices are used in everything from handheld electronics devices to network engines that act as access points. Network Storage solutions are also available.
The performance profile of these systems is similar between 6.x and 7.0. The major improvements in SMP scalability have not seemed to have an impact on the low end, single processor devices. These embedded devices have enough memory and CPU cycles to run well under FreeBSD.
The reason that I worked on the ARM port (along with many others, including Olivier Houchard, Bruce Simpson, Sam Laffler, Bernd Walter and a few my feeble memory can't recall at the moment) is two fold. First, my company needed a UNIX-like operating system, free from the GPL, that ran on a low-powered device. The ARM AT91RM9200 from Atmel was selected because it offered all the i/o pins and serial buses that were necessary to interface with the rest of the timing engine (done in an FPGA). Second, for a while I've been hearing from people that they needed a lower power, lower cost solution that runs FreeBSD than even the very nice low end Soekris boxes. I felt that by working on different embedded platforms that this would help people do that and increase FreeBSD's reach into the embedded world.
I have recently changed employment. My main job is to spearhead efforts to bring FreeBSD to the MIPS and PowerPC world. Working with the community and other companies in this space, our aim is to make FreeBSD on these platforms robust, scalable, and secure. While this work isn't going to be in 7.0, FreeBSD's reach into the embedded world will continue. The increasingly aggressive enforcement of the GPL by the Software Freedom Law Center and others has created a demand for software with a license that's easier to abide by. In addition, FreeBSD 7.0's scaling work helps it to be competitive in the higher end embedded space where everything is moving to multi-core designs.
Is FreeBSD ready for 64bit systems? Which version (amd64 or i386) would you suggest for x86-64 systems?
Ken Smith: The baseline system has been 64 bit ready for a long time now. But as we all know people who only care about the baseline system and nothing else are very rare—virtually everybody wants to run stuff on top of the baseline system. Until x86-64 systems became mainstream lots of the application software had 64-bit related bugs in it (or flat out wouldn't compile) but that has been changing now. It's gotten to the point this question isn't as simple to answer as it had been before. If you are running applications on servers my advice remains the same as it has been for a while now—give your set of applications a try on amd64 and if they seem to work consider going that way.
Several of the servers I run for work are running amd64. For desktop workstation type stuff I used to strictly recommend sticking to i386 because so much of the stuff typically used in that environment was either unavailable or buggy in 64-bit mode. I still recommend you stick to i386 if you're particularly conservative and/or tend to use lots of "multimedia/entertainment" type stuff (especially browser plug-ins, sound codecs, etc). But using amd64 has definitely become a viable alternative, if you're adventurous give it a try. My primary workstation at work is running amd64. So far the only glitch I tripped across was with the ancient thing I use to read usenet news with (xrn, don't ask why...) and I was actually able to fix it with about 15 minutes of digging around (yay Open Source). I was even able to get the backup package we use to work despite it being an i386 binary targetted at an older release (amd64 comes with 32-bit libraries that can be used to support i386 binaries, including the older sets of libraries available in the "compat" ports).
Mark Linimon: The state of the ports on amd64 does lag behind i386 a bit. Often this is due to the authors of the original software making such assumptions that an int is a pointer. If we are able to, we create patches and try to get the authors to accept them. This has become much easier over the past 2 years as more and more people are running in 64-bit mode. During this time we have seen a shift from our user base being 95% i386 and 5% amd64, to something more like 85% i386 and 15% amd64. (These figures are guesstimates, based on statistics gleaned from the problem report database).
Work is ongoing to alert port maintainers about problems on amd64 and create HTML reports showing the differences between the various build environments.
In certain cases drivers are not available for amd64 (in particular, third-party video drivers). Therefore, the suitability for 64-bit mode may depend on your application (e.g., if you are using FreeBSD as a workstation).