Be Newsletters - Volume 1: 1995–1996
Release 1.1d7 of the Be OS™ will support loadable device drivers. Hardware developers will now be able to write drivers to support their unique hardware designs. This article provides an overview of device driver design for the Be OS.
The Be OS features an "add-on" facility for dynamically loading object files and linking them to running applications. Device drivers are implemented the same way, except that they're kernel add-ons. The kernel looks for drivers at boot time in the /boot/system/drivers directory. Each driver provides a few well-known external symbols that the kernel uses to enumerate which devices the driver supports and the entry points for the five calls for accessing each device (open, close, control, read, write). The device names are made available under the /dev pseudo-directory.
Note: One problem with the current design is that the name space is not
all visible, symmetric, and otherwise perfect. In a Terminal window, you
can't enter "cd /; ls -l" and see all
the mounted volumes, or "cd /dev;
ls -l" to show all the available devices. We hope to fix this in the
future, probably when we integrate support for external file systems.
Device drivers come in two flavors: Static drivers, which support a fixed set of devices known at compile time; and dynamic drivers, which determine what devices can be supported at run time.
Static drivers are identified by the presence of the "devices" external symbol. This is a table of device_entry structures, each having a device name and function pointers for the five calls.
Dynamic drivers are identified by the presence of the
publish_devices
external symbol. This a function that returns a
table of pointers to device names. The function is called when the driver
is first loaded, and also later when someone tries to open a device with
a name the kernel has not yet seen. Dynamic drivers also must provide the
find_device
external symbol to return the device_entry structure
for a particular name that was published.
Drivers are extensions of the kernel. They're loaded in the kernel address space, and are called with the processor's supervisor mode enabled. They usually install interrupt handlers. Driver code must be sensitive to issues of reentrancy, interrupt-level execution, scheduling, and virtual memory. The kernel exports many services to make it easier for your drivers to perform a number of tasks, including:
Getting information about PCI devices
Installing interrupt handlers for either the ISA-standard 8259 interrupt controller or Be's (faster) interrupt controller
Creating critical sections in the driver code that interrupt handlers and regular calls can share
Locking and unlocking virtual buffers in physical memory (for devices that use DMA)
Locating the disparate physical memory blocks that comprise a contiguous virtual buffer
Setting up the ISA 8237 DMA controller
Sending debugging information out serial port 4 and a
kernel_debugger()
call
The PCI bus is fast, and the ISA bus is, well, ISA. Where else can you find a $19 Ethernet card? The BeBox has both PCI and ISA, and kernel services to support them.
ISA devices usually are hardwired to one of the IRQ lines on the ISA bus
(we don't support ISA Plug-And-Play yet). If the device depends on the
edge-sensitive interrupt controller found in the PC world, it uses the
kernel routine install_isa_interrupt_handler to attach its handler to a
particular IRQ in the ISA interrupt dispatcher. If it can generate a
level-sensitive interrupt, it uses the install_io_interrupt_handler call
to attach to the appropriate ID in Be's interrupt dispatcher. Be's
interrupt dispatcher is a bit faster.
PCI devices always use Be's interrupt mechanism. The driver code looks up
the PCI device (using the get_nth_pci_info call), extracts all the
information about how the device has been mapped into the system, and
also extracts the interrupt ID to use.
Device drivers often include a sequence to access a data structure or hardware registers that must be done atomically, both in the regular routines and in the interrupt handler. The kernel exports routines for implementing these critical sections.
disable_interrupts() and restore_interrupts() control the interrupt
enable on the current processor and acquire_spinlock() and
release_spinlock() control access between CPUs. A typical sequence is:
cpu_statusold_status; spinlock *lock; /* assumes lock was initialized */ /* with create_spinlock() when driver was loaded */old_status=disable_interrupts();acquire_spinlock(lock); /* do stuff in this critical section */release_spinlock(lock);restore_interrupts(old_status);
Applications would typically use a semaphore to accomplish this. Drivers typically don't want to be rescheduled before entering the critical section, and must therefore use these kernel primitives.
The goal of an interrupt handler is to do its job quickly and exit. Polling hardware, lengthy data structure manipulations, and other time-consuming operations are discouraged. The typical sequence for an interrupt handler is:
Read/write the new data or status that caused the interrupt
Manipulate the hardware to deassert the interrupt
Optionally, release a semaphore that will unblock some thread waiting for the interrupt to have occurred
Releasing the semaphore must happen after all hardware manipulations, as it may cause a reschedule. Rescheduling at the end of the handler is safe -- the interrupted thread will run again soon enough, and exit the interrupt handler at that time.
Loadable device drivers provide a flexible mechanism for supporting a wide variety of hardware in the BeBox. Many cards already exist for the PCI and ISA bus architectures. Starting with release 1.1d7, we can all start writing drivers for the Be OS to support this wealth of existing hardware, as well as inventing new devices tuned to the unique capabilities of the BeBox.
No one can deny that the Internet is going mainstream. Just flip through the latest issue of Life magazine and you'll see web sites in the print advertisements from Buick, Toyota, and Plymouth. Can Publishers Clearinghouse Sweepstakes e-mail entries be far behind, we wonder? Probably not, if John Buckman, principal of Shelby Group, Ltd., has anything to do with it. And they just might be using the BeBox to do it.
Buckman's company has been developing Internet software for four years. Currently they're focusing on helping organizations with large, geographically distributed customer bases take better advantage of the communications capabilities of the Internet. That's why his company, a Be developer, is developing WorldBase, an e-mail list server for managing e-mail lists and facilitating group discussions on the Internet.
"Besides being far less expensive than postal mail, electronic mail allows highly targeted information distribution. Current e-mail list servers were written ten years ago and can't handle the load of the 'new' Internet. Because they process things one at a time, large jobs can easily bog down and delay other jobs. When you're dealing with large e-mail lists, this is a very real problem. A new approach needs to be taken."
Buckman sees great potential for the BeBox as a cost-effective, user-friendly alternative to UNIX for serious applications. "We're targeting the BeBox as a server platform, because PC and Macintosh clients don't care what server platform you're running. With its scalability and strong multithreading, the BeBox is the perfect vehicle for an e-mail list server for today's Internet. With its friendly graphic interface and low cost, we think we can entice people to buy a BeBox to try out WorldBase."
Magazine publishers, for example, have been talking to Buckman about their desire to distribute massive amounts of electronic information using e-mail list servers. "There needs to be a solution for these kinds of customers. I'm hoping a $10,000 super-BeBox will be a far more attractive proposition to them than a $100,000 UNIX server."
The BeBox's scalability is particularly attractive to Buckman. "I'm selling a server program that needs to accommodate varying loads of use. Small users will probably buy the Windows or Macintosh versions of WorldBase. However, many companies will phase-in Internet software. They might start with a pilot project of ten mailing lists of 5,000 people on each list. And if that succeeds, they'll try to put 50,000—even 500,000—people on each list. Scalability is key, and the BeBox has it."
When people ask Buckman why he's developing WorldBase for the Be platform, he puts it this way: "Do you want the power, scalability, and robustness of the best UNIX platforms as well as something that's as easy to set up and use as a Macintosh? If so, then you need a BeBox!"
WorldBase is written from the ground up in C++, allowing for easy deployment on multiple platforms including Windows 95/NT, OS/2, Macintosh, Be OS, and several UNIX platforms. It is also programmable, and includes interfaces to popular databases including Oracle and Sybase.
Shelby Group, Ltd. hopes to release WorldBase for the BeBox in the Fall of 1996.
For more information, send an e-mail message to worldbase@shelby.com or visit their web site: http://www.worldbase.com.
What are these Apple stories? David Coursey writes a leading industry newsletter, PC Letter. In an issue immediately following our first public appearance at Agenda, David reviewed the BeBox rather kindly, making more than passing reference to Apple. At the same time, Stewart Alsop ran an InfoWorld editorial equating the BeBox to what Apple could have, should have done. These articles amused a few insiders. Thankfully, no one else seemed to pay much lasting attention.
Two weeks ago, David Coursey wrote a more pointed lead piece in an open letter to Dr. Gil Amelio, Apple's brand new Chairman and CEO. Open letters are a regular and often tart feature of PC Letter. Many CEOs, from Jim Manzi to Lou Gerstner, have thus received advice ranging from acquisitions to resignation. This time Dave gravely informed Dr. Amelio that yours truly had never left Apple. Be was, in fact, a super-secret Apple project, a skunk works team designing the next generation Macintosh. In spite of the tongue-in-cheek tone of the piece and the explicit "not true" at the end, it has been taken seriously, generated some interesting, incredulous, or nervous e-mail.
While discussing speculation might have the perverse effect of giving it more currency, I think this is a good opportunity to set the record straight on this and other related Apple matters.
While we're honored and amused by the idea, we're not an Apple skunk works. But, in a way, we are. About half of us come from Apple. As a result there is a real and perceived connection. Then again, about half of us own and operate Psion pads. This doesn't make us a secret Psion business unit.
Seriously, we need to acknowledge our debt to the old company. Living inside the sausage factory, we gained an appreciation for the difficulties of incrementally evolving system software and developed a hunger for a simpler life, technically and organizationally. We gained a better understanding of the relationship between the mores, the size, the spending habits, the politics of an organization and its output, the product. When we showed our work to Taligent employees late last year, they cheered. They said, "This is Pink." Indeed, after the Macintosh II shipped in 1987, we started thinking about life after Macintosh. What had we learned, what would we do if we were granted a fresh start, a blank slate? These conversations led to a project called Pink, later transferred to the Apple-IBM joint venture, Taligent, subsequently abandoned when the two companies felt there was no promise in a new operating system. In August 1990, two months before I got off the Apple payroll, I had a casual conversation with John Sculley at a Claris party. The disagreements leading to my resignation in February 1990 were behind us and we were both in a good mood. I told John I needed to get one more thing off my chest before leaving. I suggested he cancel Pink and blame it on me. The project had grown too big, too rich, too fat, with too many politically correct goals, trying to have both feet firmly planted in the past and in the future. The corporate lymphocytes, hard to avoid in a large organization, had selected away the kind of hard-ass leadership needed for such a project, someone like Dave Cutler driving Windows NT. I felt responsible and wanted the situation rectified. The problem wasn't solved until much later, but we're richer for the experience.
And, yes, David Coursey must have pretty good antennae, or sources at the highest level at Apple. A year ago, I met with Michael Spindler and the subject of cross-licensing came up. I felt, and still feel, we were in the same PowerPC camp and I suggested we enter a cross-licensing agreement. Michael suggested we focus on the upcoming Common Hardware Reference Platform (called PPCP this week): Licensing the MacOS would be a much simpler matter and it could offer the Be OS a nice playing field. Hence my earlier statements here: "We'll be happy to help and benefit as the new platform gains momentum. But this is for the 1997 horizon." The other side of the cross-licensing agreement would have been access to the Be OS. I suggested it, perhaps prematurely, as some kind of insurance against Copland being beset by the same problems that affected Pink. As we know, nothing came of these discussions. Dave could have been prescient; instead he was only inspired, or well informed.
After several weeks of presence, Be is gaining interest in countries all over Europe and beyond. Developer Forms have come in from Reykjavik to Vladivostok. Some of these developers have been programming on their BeBoxes for months, while others will receive machines in April. We've even seen alpha versions of some applications.
Who is doing what and where? The following tables should give you an idea of how BeBoxes and Be developers are distributed across Europe (as of February 29):
Be Developer Forms Country Qty. % ---------------------- Austria 2 1% Belgium 8 3% Denmark 7 3% England 36 15% Finland 4 2% France 95 38% Germany 30 12% Greece 1 - Hungary 2 1% Iceland 2 1% Ireland 3 1% Israel 2 1% Italy 5 2% Netherlands 14 6% Norway 12 5% Portugal 1 - Russia 1 - Spain 1 - Sweden 11 4% Switzerland 10 4% Turkey 1 - ----------------------- Total: 248 100% BeBox Owners Country Qty. % ----------------------- France 29 47% Germany 9 15% England 6 10% Norway 4 6% Switzerland 4 6% Netherlands 2 3% Sweden 2 3% Belgium 1 2% Finland 1 2% Iceland 1 2% Ireland 1 2% Israel 1 2% Portugal 1 2% ----------------------- Total: 62 100%
At Be, we believe that developers should have as much contact with each other as possible. During the GeekFest, we invited developers to fill out Developer Exchange forms. The information we collected through these forms will be available soon on the new Be Europe web site (http://www.beeurope.com). This new site also includes a mirror of the American Be web site.
If you didn't get a chance to fill out a Developer Exchange form, or if you'd like to update the public information concerning your application, we encourage you to send this information to us. By posting news of your work, your colleagues will have the opportunity to contact you and share ideas, suggestions—and maybe even bugs.
To continue in our effort to meet our developers—and to introduce you to each other—we're preparing a European tour for April. We're planning to give presentations, answer questions, and in general, provide a gathering place for Be sympathizers in a number of cities. If you're a registered Be developer, if you're thinking about it, or even if you just want to see the BeBox, simply get in touch with our office in Paris (droulers@BeEurope.com) for a copy of our itinerary. Tell your friends! We haven't yet determined the exact places where these events will take place (we plan to start the tour in England and then swing through Scandinavia and Germany). We'll try to arrange our visits so we can meet as many of you as possible—so let us know where you are and we'll try to come to you. If you have access to an assembly place (a university or school hall, a large meeting room, or a similar venue), or if you can offer advice on good places to meet in your area, we'd love to hear about it. Finally, we have changed our e-mail addresses. Use these for any questions you have regarding European topics:
General information: infobe@BeEurope.com
Sales, distribution: jcalmon@BeEurope.com
Developer information: droulers@BeEurope.com
Developer support: devsupport@BeEurope.com
Order processing: mclevrat@BeEurope.com
Use this occasion to send us a message with news about your Be projects.
