Be Newsletter
Issue 5, January 10, 1996
Table of Contents
BE ENGINEERING INSIGHTS:
From Power Up to the Browser: How the Be OS Starts Up
By Bob Herold
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 Boot ROM
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
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 Shared Library: libbe.so
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.
The Shared Library: libpos.so
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
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
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 Zoo Keeper
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
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
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
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
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
The Net Server implements the TCP/IP protocols needed to
communicate with other devices over an Ethernet or PPP
connection.
The Name Server
The Name Server assists the Net Server in managing
various system resources, such as ports and semaphores.
ftpd
ftpd is the ftp 'daemon.' It runs in the background,
silently providing ftp access to the BeBox.
Summary
The Be OS is divided up into many different components.
Hopefully this article has shed some light on how they are
started up, and what they do.
MacWorld? What Are We
Thinking?
By Jean-Louis Gassée
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.
Be Marketing Questions
and Answers
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.
Q: When is the BeBox going to be on sale?
A: Be plans to make the BeBox available to the
general public in the first quarter of 1996. This means that
you will be able to purchase a BeBox (configured with
peripherals or not) from Be or from one of its resellers or
VARs, with the native Be CodeWarrior development environment
bundled. During 1996, we expect most purchasers to be
programming hobbyists and professionals who are developing
software for their own use, or for eventual sale to other
BeBox owners.
Q: What will it cost?
A: Be has not set its final pricing for the
initial BeBox configurations, partly because we expect
component prices to continue to change (read "fall") prior
to our release date. We've announced that we expect the
pricing to be about $1,600 for a bare-bones (non configured)
system, and estimate that a configured system will be in the
$2,500 range. We'll announce firm prices as the release date
approaches.
Q: Where can I buy a BeBox?
A: Initially, we expect that you will be able to
purchase the BeBox from three sources. First will be through
our resellers and VARs. Second will be directly from Be, via
the Internet. In this case, your order will be sent to one
of several partner companies, depending on the configuration
you order. Last, we expect the BeBox to be made available
through organizations such as universities. More details
will be available as we approach our initial ship date.
Q: What are Be's plans for distribution outside the
U.S.?
A: Be does plan to distribute outside the U.S. In
fact we already have a developer program up and running in
Europe and have established corporate offices in Paris,
France, for developer services and marketing activities.
European developers can contact our Paris offices directly
at:
devbe@beeurope.worldnet.net.
Be plans to initially release the BeBox in the U.S. and
France. After the initial release we plan to expand
distribution to other European, Asian, and Pacific countries
as quickly as we can. Our main gating item will be
identifying distribution and other partners in the various
countries and regions. We invite interested parties to send
us questions and information to either
marketing@be.com or
devbe@beeurope.worldnet.net.
To set expectations correctly, the Be OS will initially be
released in English. We expect to release other versions of
the Be OS in other Roman-character languages as quickly as
possible. We will post information about these releases to
the Be web site after the initial English release. Be is
committed to developing the Be OS in multibyte language
forms, but we haven't announced our plans yet.
|
