Dennis wrote: > Hi, > > I just wanted to ask how driver development is done at Solaris? > - Do you ask hardware makers for the specs?
Ideally, yes. In some cases, it's even possible to develop drivers from publicly available documentation; I wrote the original incarnation of the 'pcn' PCnet-PCI network driver in Dec-1994/January-1995 entirely from the AMD databook anyone could buy at the time. At the time, the pcn driver supported the entire NE2100/LANCE family (7990, 79C90, 79C960 ISA, 79C965 VL-bus and 79C970 PCI); I spent a day or two tripping over minor bugs in the 32-bit support in the PCnet parts in the real-mode boot driver. In late 1995, I prototyped drivers for the AT&T WaveLAN 915 adapters; I did have access to the AT&T documentation under NDA at the time. These adapters were really just Intel NICs with the Ethernet MAC interface replaced with a 2Mb/s half-duplex radio, so the AT&T documentation primarily documented the radio interface and required timing parameters; for the actual network driver code, I used the standard, off-the-shelf Intel databooks. First, I developed the PC-Card/PCMCIA WaveLAN driver from the Intel databook; that NIC used a somewhat unusual Intel NIC that used a FIFO for interface to the host. The Intel databook did a good job of documenting the part, though the part was not capable of really high performance; I measured TCP throughput at - IIRC - 1.5Mb/s. I couldn't saturate the 2Mb/s network with that card. The WaveLAN ISA board was based on the then-ubiquitous Intel 82586 NIC and I'd had enough experience with other 82586 drivers of variable quality that I decided I wanted to build my own driver for that chip and "do it right". So I went home for a few days with the Intel databook, and wrote most of the driver code without compiling it even once (normally, I'd use a bit of an Extreme Programming approach and unit-test each major function individually, starting with attach()/detach(), then send()/receive(), then the multicast support and whatever is left over). At the risk of gratuitous boasting, once I took that driver to work and compiled it, I found maybe a half-dozen typos, and the driver actually compiled on the third try. It even mostly worked at that point; once I started stress-testing it, I found a bug, which I fixed. Within a few hours, the driver appeared stable. After I self-reviewed the code, I cleaned- up a few things and compiled the driver once or twice more the next day. I used that binary without recompilation to run a wireless gateway at home for the next three years without encountering a problem. I still can't believe I wrote 1500 lines of code for the fairly complicated Intel 82586 NIC and never had to fix a bug in deployment. One of my goals in building yet- another 82586 driver was to fully utilize the ring-buffer capability of the 82586; as a result, I consistently measured TCP throughput just under the physical max of 2Mb/s and easily saturated the 2Mb/s network. In 1996, I built a driver for the NE2000/DP8390 which I did not integrate into Solaris using the standard off-the-shelf National Semiconductor databook; this was more challenging since the DP8390 had a number of quirks that were faithfully reproduced in other parts (like the Realtek PCI clone) and not documented in the off-the-shelf databooks at the time. Note that all of the above parts were reasonably mature at the time I was building drivers for them, and databooks were readily available. Modern parts are developed in much faster timescales and there's often no publicly-available datasheet when the parts come out. Even when there is a datasheet, the parts tend to rev quickly enough that the datasheet might always lag behind. The best-supported new parts are the ones which developers have access to the datasheets from the manufacturer, so it really pays to develop relationships with the manufacturers. > - Do you do reverse engineering? In my experience, the closest to reverse-engineering I usually get is figuring out undocumented chip quirks. > - Do you look at oher drivers from Linux or BSD? Within the bounds of IP license restrictions, yes. In fact, I'm much more inclined to leverage community source when possible than I was ten years ago. Everyone wins this way; I'd rather have one version of a driver that's tested on many OSes than 5 versions of drivers even if this means I don't get to start from scratch and "do it right" as often :-). It's quite rewarding to be able to contribute back to a community and have my contribution running on nearly all the non-Windows machines after some time (as is the case with contributions to Intel ACPI CA community). > Another question: How many Solaris developers are there at Sun? I don't know. There's a pretty good crowd in the OpenSolaris community, though. > Last question: I´ m looking for a real hardware raid for SAS and SATA for > Solaris. Is there anything else than Areca and HP? Adaptec and 3ware seem > not to work, according to their websits? Not to deflect your question, but have you considered running ZFS on top of a multiport SATA card without "hardware" RAID? From a data reliability perspective, this arguably gives you the best results and allows you to trade-off reliability, performance and space-efficiency as desired. Just in the last week, there have been two reports from users of ZFS in which errors in their storage systems were discovered using ZFS and had previously been quietly corrupting data. Dana _______________________________________________ opensolaris-discuss mailing list [email protected]
