103 lines
12 KiB
HTML
103 lines
12 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Be Newsletters - Volume 5: 2000</title><link rel="stylesheet" href="be_newsletter.css" type="text/css" media="all" /><link rel="shortcut icon" type="image/vnd.microsoft.icon" href="./images/favicon.ico" /><!--[if IE]>
|
||
<link rel="stylesheet" type="text/css" href="be_newsletter_ie.css" />
|
||
<![endif]--><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Be Newsletters" /><link rel="up" href="volume5.html" title="Volume 5: 2000" /><link rel="prev" href="Issue5-1.html" title="Issue 5-1, January 5, 2000" /><link rel="next" href="Issue5-3.html" title="Issue 5-3, January 19, 2000" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue5-1.html" title="Issue 5-1, January 5, 2000"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="volume5.html" title="Volume 5: 2000"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="Issue5-3.html" title="Issue 5-3, January 19, 2000"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="headerTR"><div id="navigpeople"><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div><div class="navigboxed" id="naviglang" title="English">en</div></div><div id="headerTC">Be Newsletters - Volume 5: 2000</div></div><div id="headerB">Prev: <a href="Issue5-1.html">Issue 5-1, January 5, 2000</a> Up: <a href="volume5.html">Volume 5: 2000</a> Next: <a href="Issue5-3.html">Issue 5-3, January 19, 2000</a></div><hr /></div><div class="article"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Issue5-2"></a>Issue 5-2, January 12, 2000</h2></div></div></div><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering5-2"></a>Be Engineering Insights: Just How Much BeOS Do You Really Need?</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Trey</span> <span class="surname">Boudreau</span></span></div></div></div><p>
|
||
As developers, you're probably aware that BeOS is a layered system. The
|
||
kernel is at the bottom with its drivers and modules, followed by a few
|
||
libraries (root, net, textencoding), various servers (app, input,
|
||
registrar, net), a few more libraries (be, netdev, tracker) and finally,
|
||
applications. The whole collection makes a wonderfully synergistic
|
||
system. But just how much of that stack do you really need?
|
||
</p><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id465857"></a>It <span class="trademark">Depends</span>™</h3></div></div></div><p>
|
||
What do you want to do? Occasionally, a demo coder thread erupts on
|
||
BeDevTalk. Invariably, someone laments about the overhead of this or that
|
||
feature of the OS. Without commenting on the relative merits of these
|
||
discussions, I can tell you how to get as close to the silicon as you can
|
||
without writing your own drivers. But to do that, we have to decide what
|
||
we don't need.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id465877"></a><acronym class="acronym" title="Rest In Peace">R.I.P.</acronym> app_server</h3></div></div></div><p>
|
||
If you want to get close to the hardware, you've got to go around the
|
||
app_server. Or better yet, not run it at all. Once you take this step,
|
||
every other server in the OS is useless, so they can go too. Because
|
||
networking runs as a server (at least until <acronym class="acronym">BONE</acronym> shows up), networking is
|
||
right out. No servers means no <code class="filename">libbe.so</code> and friends. Just about the only
|
||
thing left is <code class="filename">libroot.so</code>, but that's quite a bit. You still have just
|
||
about all the <acronym class="acronym">POSIX</acronym> we support, plus access to BeOS-specific features,
|
||
such as loading add-ons and creating semaphores. This means any class of
|
||
driver for which you know the <code class="function">ioctl()</code> API is still usable. We'll get back
|
||
to this in a bit.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id430893"></a>Booting BeOS</h3></div></div></div><p>
|
||
By systematic trial and error, you'd find that you need very few files to
|
||
boot BeOS. I'll save you some time and tell you what you need for the
|
||
loader to boot to a particular partition. You'll definitely need the
|
||
kernel (and <code class="filename">zbeos</code> on x86 hardware), and whatever drivers/busses/modules
|
||
support your particular hardware. You'll need the accelerant for your
|
||
graphics card(s). And you'll need two other files: <code class="filename">/boot/beos/bin/sh</code> and
|
||
<code class="filename">/boot/beos/system/boot/Bootscript</code>. Bootscript can be empty, but it must
|
||
exist. <code class="filename">sh</code> is the program the OS executes to get things started. BASH is
|
||
nice, as shells go, but not needed for this operation, so I decided to
|
||
replace it with my application. For getting started, you can just replace
|
||
sh with your own app, but for grins I removed (almost) everything that
|
||
wasn't required for my particular hardware. 'du -k /test/beos' reports a
|
||
measly 2493K.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id430933"></a>The Demo</h3></div></div></div><p>
|
||
NOTE: I Am Not A Demo Coder. Besides, this was not really an exercise of
|
||
my demo coding skills. I'm just the point man, and I've discovered these
|
||
two tips/traps:
|
||
</p><ul class="itemizedlist"><li><p>
|
||
To aid debugging, you'd like to keep a log file (and/or generate
|
||
serial debug output). Calling <code class="code">freopen("/boot/var/log/demo.out", "w",
|
||
stdout)</code> is useful in this respect. You can do what you like with the
|
||
other standard file handles. In my program I get <code class="filename">stdin</code> from <code class="filename">/dev/null</code>
|
||
and <code class="code"><code class="function">freopen</code>("/boot/var/log/demo.err", "w", <code class="varname">stderr</code>)</code> in case something I
|
||
load as an add-on uses it. You can also call <code class="code"><code class="function">disable_debugger</code>(1)</code> and
|
||
arrange for your app to get all the signals itself, but I don't do that
|
||
in the demo.
|
||
</p></li><li><p>
|
||
Set the <code class="envar">ADDON_PATH</code> and <code class="envar">LIBRARY_PATH</code> environment variables. If you
|
||
don't, <code class="function">load_add_on()</code> will fail—even if you specify a full path to
|
||
the add-on.
|
||
</p></li></ul><p>
|
||
The meager demo application can be found at:
|
||
<ftp://ftp.be.com/pub/samples/graphics/SlimDemo.zip>
|
||
</p><p>
|
||
If you've ever looked into the test harness shipped in the R4 Graphic
|
||
Driver Kit, chunks of the sample code would be eerily familiar.
|
||
Programming at this level is fairly unexciting, and this code is no
|
||
exception. The <code class="function">main()</code> function initializes the standard file descriptors
|
||
and environment variables mentioned above, and then spawns and waits on a
|
||
thread to handle the display chores.
|
||
</p><p>
|
||
The spawned thread hunts down and opens a graphics device, and then
|
||
attempts to load the corresponding accelerant (R4 graphics drivers are
|
||
two-part beasts, as is common under BeOS). After the accelerant is
|
||
loaded, the code sets the first reported display mode and then begins the
|
||
cheesy (and short) "animation." I didn't bother to set up and use
|
||
hardware acceleration, but it's easy to do, and the harness program in
|
||
the driver kit will show you the way. When the animation finishes, the
|
||
accelerant is uninitialized and unloaded, and the device is closed. The
|
||
thread terminates, and shortly thereafter so does the application,
|
||
leaving the kernel silently in charge of the machine.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id431029"></a>B_DONT_DO_THAT</h3></div></div></div><p>
|
||
A friendly <acronym class="acronym" title="Developer Technical Support">DTS</acronym>
|
||
staff member pointed out that while you can run the sample
|
||
code while the full BeOS is running, you won't like the results. The
|
||
current driver model doesn't do anything in the way of preventing you
|
||
from opening and initializing the graphics device if it's already
|
||
running. If you have specific combinations of graphics cards in your
|
||
machine (and a <acronym class="acronym" title="Basic Input/Output System">BIOS</acronym>
|
||
that isn't broken, but that's another story), you can
|
||
open and control the other graphics card(s). You might also consider not
|
||
replacing <code class="filename">/boot/beos/bin/sh</code> on your primary boot partition, but rather
|
||
making yourself a tiny test partition to play with. Caveat Programmer.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id430692"></a>Now What?</h3></div></div></div><p>
|
||
That's pretty much up to you. Access to other devices is mostly a matter
|
||
of issuing the right <code class="function">ioctl()</code> calls. If you can't find them documented in
|
||
the BeBook, in headers, or in some newsletter article, e-mail me. One of
|
||
you d00dz write a l33t dem0, and show me just how lame my example really
|
||
is.
|
||
</p></div></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue5-1.html">Issue 5-1, January 5, 2000</a> Up: <a href="volume5.html">Volume 5: 2000</a> Next: <a href="Issue5-3.html">Issue 5-3, January 19, 2000</a> </div><div id="footerB"><div id="footerBL"><a href="Issue5-1.html" title="Issue 5-1, January 5, 2000"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="volume5.html" title="Volume 5: 2000"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="Issue5-3.html" title="Issue 5-3, January 19, 2000"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="footerBR"><div><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div></div><div id="footerBC"><a href="http://www.access-company.com/home.html" title="ACCESS Co."><img alt="Access Company" src="./images/access_logo.png" /></a></div></div></div><div id="licenseFooter"><div id="licenseFooterBL"><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" title="Creative Commons License"><img alt="Creative Commons License" style="border-width:0" src="https://licensebuttons.net/l/by-nc-nd/3.0/88x31.png" /></a></div><div id="licenseFooterBR"><a href="./LegalNotice.html">Legal Notice</a></div><div id="licenseFooterBC"><span id="licenseText">This work is licensed under a
|
||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative
|
||
Commons Attribution-Non commercial-No Derivative Works 3.0 License</a>.</span></div></div></body></html>
|