Be Newsletters - Volume 1: 1995–1996
The Be OS is composed of a boot ROM, a kernel, several 'servers,' and a shared library that exports the Be API. If you issue a ps command in the Terminal window, you will see that many of these components have several threads. This article describes all these items, how they get started, and what they do.
The flash memory device on the motherboard contains the boot ROM. It's partitioned into sections, including a small "nub" and a main part.
When you turn on the BeBox, CPU 0 starts running in the nub, while CPU 1 is held in reset. The nub's job is to locate, size, test, and configure the memory, check the floppy drive for a special Boot ROM Upgrader disk, and then pass control to the main part of the boot ROM.
The main part of the boot ROM has the single-minded task of locating a kernel on one of the disks attached to the BeBox. It searches in a particular order: Floppy, removable disks (such as CD-ROM drives or removable hard disks), the disk specified by the boot preference (set by the Installer or the boot command), SCSI fixed disks (scanning from SCSI ID 0 to 6), and IDE disks (master first, then slave). If a kernel is found, it's loaded and run.
Before CPU 0 rummages around for a kernel, it releases CPU 1 from reset. CPU 1 quickly jumps from the nub to the main part, and displays the swirling Be logo. CPU 1 then idles until CPU 0 is in the kernel and ready to run with both CPUs going full bore.
The kernel is started by CPU 0. It sets up all the basic necessities (semaphores, threads, teams, the scheduler, areas, ports, interrupts, inter-CPU communication, virtual memory, idle threads), and then lets CPU 1 join the party. Either CPU can run any thread from the ready queue, so multiprocessing just happens naturally when the code is structured into separate threads.
The kernel starts up several internal housekeeping threads:
idle threads 0 and 1: | Each CPU must always run something. The idle threads are simple spin loops, with a scheduling priority of zero. They never block, so they're always around when there's nothing else to do. |
psycho-killer: | Having a thread kill itself is tricky. It's much easier to hire out for the job. The psycho_killer thread assassinates threads that wish to die, and removes a team when the team's threads have all died. |
idle debug 0 and 1: | These are around in case something bad happens in the idle threads. They take over debugging chores from the idle threads, thus allowing the idle threads to continue loafing on the street corner. |
dprintf and dgets: | These are for kernel debugging. If you hold down the F1 key when you boot, all sorts of debugging spewage comes out of serial port 4 at 19.2 kilobaud. Should the kernel crash, a primitive debugger is available there. These two threads manage the debugging I/O to the serial port. |
floppy motor off: | A floppy drive takes half a second to spin up to speed. Rather than turning the motor off after each read or write, it's left running for a few seconds in case another access comes along. This thread turns the motor off after this grace period. |
disk cache: | The file system has a cache. This thread periodically writes dirty sectors from the cache to disk. Note that disk accesses greater than a certain size bypass the cache entirely. |
Once these niceties are set up, the kernel mounts all available disks and
looks for a disk from which to boot the rest of the system. Disks are
examined to see if they have a complete set of system software: the
Browser, the Application Server, the Storage Server, the Zoo Keeper, a
drivers directory, and the shared libraries
libbe.so and libpos.so. If
any of these files are on the floppy, they take priority over these files
on other disks.
The kernel looks for system files on disks in the following order: The floppy disk, the volume where the kernel was found by the boot ROM, the disk specified by the boot preference, SCSI disks 0-6, IDE master, and IDE slave. The first disk with all the system files, minus any contributions from the floppy, becomes the "boot volume." If the boot volume is writable, it's also used as the volume where the virtual memory backing files are kept; otherwise, virtual memory is disabled.
Once the boot volume is identified, the Application Server, Storage Server, Zoo Keeper, and the Browser are started from the boot volume (or the floppy). Additionally, the kernel looks for a file called Bootscript, and starts up a shell to interpret it. The current Bootscript launches the ANSI Server, the Audio Server, the Debug Server, the Name Server, the Net Server and ftpd.
The libbe.so shared library exports the API described in The Be Book.
Applications link with the shared library at compile time, and are bound
to the shared library when they are loaded at runtime.
The shared library together with the various servers implement the API. The library uses the kernel's port mechanism and shared memory to communicate with the servers. API calls are converted into messages and sent though a port to a thread in the appropriate server. Servers usually allocate a single thread to manage each client, allowing for concurrent access to the functionality each server provides. The allocated thread receives the message, carries out the call, and often returns results to the client via another port.
libpos.so provides an emulation of some of the Posix API. This makes
porting of UNIX-flavored software much more feasible. Many of the
command-line tools available in the Terminal application use this library.
The Application Server, in conjunction with the Application Kit and the Interface Kit, manages an application's user interface, graphical environment, and messaging infrastructure. All these are extensively documented in The Be Book.
The Application Server has a few permanent housekeeping threads, plus a separate thread for each client application and each client window. The housekeeping threads are:
poller: | Collects keyboard and mouse information from the kernel, forwards it to the app_server thread, and displays the on-screen cursor |
app_server: | Handles set-up of new applications; dispatches keyboard and mouse events to the appropriate window thread, which sends them to the client |
picasso: | Receives notification from the kernel of various interesting events, such as a thread being destroyed |
The Storage Server is the database engine. The Storage Server manages the index into the databases and performs the queries associated with each database.
The functions described in "The Storage Kit" chapter in The Be Book are
actually split between the Storage Server, the Zoo Keeper, and the
libbe.so shared library. The Zoo Keeper, keeps track of volumes, ensuring
that every volume has a database that describes the volume's file system
hierarchy. The actual management of files and directories (BFile,
BDirectory, BVolume) is split between the shared library and the Zoo
Keeper. Both use the Storage Server to maintain the database view of the
file system. Interestingly, the Zoo Keeper and Storage Server are also
linked with the libbe.so shared library to gain access to each other, the
kernel, and the Application Server.
The Browser is what you see when the machine has started up. Its powerful capabilities are sure to be the subject of a future newsletter article. Strictly speaking the Browser is an application like any other—it links with the shared library and uses the various servers and the kernel to go about its business. Obviously it's one of the more important applications shipped with the BeBox.
The ANSI Server is an anachronism, which will soon go away. It provides ANSI-style terminal windows to clients, communicating through named pipes with the client. It has been replaced by a new TTY driver, which understands how to emulate an ANSI terminal. In earlier releases, the shell used the ANSI Server, but it has been converted to use the TTY driver. The Debug Server has not yet been converted, so we'll have the ANSI Server around for a little longer.
The Audio Server provides the functionality described in "The Media Kit" chapter of The Be Book. Streams, Stream Controllers, and the Subscription mechanism are all handled here.
Two housekeeping threads, DAC Feeder and ADC Feeder, keep sound buffers flowing smoothly to and from the sound driver (which manages the audio CODEC). Requests to play or record sounds instantiate a thread that manages the process.
The Debug Server implements the assembly-level debugger. When an application crashes or runs into a debugger() call, the kernel spawns a per-team debugging thread in the application's address space to manage communication with the Debug Server. The Debug Server, in turn, spawns a thread to put up a window for that team (currently using the ANSI Server) and to process debugging commands. The kernel provides hooks for installing a different debugger on a per-team basis. Our friends at Metrowerks are creating a source-level debugger using this facility.
The Net Server implements the TCP/IP protocols needed to communicate with other devices over an Ethernet or PPP connection.
The Name Server assists the Net Server in managing various system resources, such as ports and semaphores.
ftpd is the ftp 'daemon.' It runs in the background, silently providing ftp access to the BeBox.
This is a Macintosh trade show. You're not selling Macs, you're not a Mac OS licensee, the BeBox isn't even a CHRP platform, and in any case, with your "geek" positioning, you're definitely not addressing the needs of mainstream Mac users. So, what are you doing here?
Good question. A few months ago, I would have agreed we had no business going to MacWorld. And today, I agree with all the facts stated above. But they're not relevant to our decision to exhibit in San Francisco. Here's why, with the hope it will shed some light on our marketing strategy. No, we're not selling Macs and we're not a Mac OS licensee although,at some point, we considered it. Early in 1995, friends at Apple advised us to wait for a new hardware reference platform. Eventually, Copland would run on that platform and all compliant hardware would run the new Mac OS. No need to be a licensee, just buy the OS off the shelf and you can run Mac applications.
Indeed, the CHRP platform was announced at Comdex, with a partial release of technical data. Specs for the ISA system and a few other details are expected soon and, given the updated Copland schedule, Apple announced it will make a 7.5.x version for CHRP, with the first machines to appear in late 1996 or the first half of 1997, depending on the source. As the CHRP specs are finalized and parts vendors start supplying chip sets, making a CHRP compliant multiprocessor BeBox with its rich, geeky I/O becomes an attractive proposition. As the current BeBox is based on the ancestor of CHRP, PREP, it's logical for Be to make CHRP an important part of its product strategy. Today's PC clones are still built around a core of PC/AT design. Compliance to these specs has allowed PC buyers to benefit from a number of operating systems: DOS, Windows and Windows NT, of course, but also a number of UNIX variants, NEXTSTEP, Linux, OS/2, and I must forget a few. The CHRP partners hope to see a like diversity of system software on the PowerPC side. We'll be happy to help and benefit as the new platform gains momentum. But this is for the 1997 horizon.
What about MacWorld in January 1996, geeks, and mainstream Mac users? Representing MacWorld as only attended by bourgeois mainstream users is quite a stretch. Yes, we see more suits than T-shirts today than ten years ago, but there's always a strong contingent of aggressive, knowledgeable users, exhibitors, and software developers. They're not always found around the bigger, jazzier, and more expensive booths, and that's fine with us. They're our audience—they come to MacWorld in sufficient numbers to more than justify our presence. Three months ago, at the Agenda conference, we showed the BeBox to an audience of professional cynics—or cynical pros. We were surprised by the exceptionally warm reception. This continued as our Web site opened. We now have more than 900 requests for development systems from all over the world, and the new comp.sys.be newsgroup is lively. As a result of a higher than expected level of interest, of "pull," we decided to go beyond the "Demo Days" at Be in Menlo Park. Three months after Agenda, MacWorld happened to be a nicely timed and geographically positioned venue.
For the more committed, you decide the sense, we'll host our first software developer conference, our first "GeekFest," right after MacWorld on Saturday, January 13, in South San Francisco Convention Center.
Back to our MacWorld booth: We'll make sure mainstream users aren't misled. We'll prominently display a surgeon general's warning: Unfit for consumption by normal humans. We'll focus on software development tools, the new version of CodeWarrior by Metrowerks, prototypes and works in progress from early Be developers, and BeBox demonstrations every 20 minutes. This is our first public appearance. Come by if you can. You'll get your free We Be Geeks pocket protector.
Here are a few answers to a number of the most common questions you've been asking about Be. We'll keep you informed regularly about Be marketing, sales, pricing, and the like.You can also check out our web site at: http://www.be.com.
