summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDenys Vlasenko <vda.linux@googlemail.com>2011-03-07 14:21:51 (GMT)
committer Denys Vlasenko <vda.linux@googlemail.com>2011-03-07 14:21:51 (GMT)
commitcc7de179d4c2160022e170a2aa7f0282d18c28fa (patch)
tree86901422fb1a2d8519d08ff1040acd9028524dd5
parentc82842fa1577e79fb773f0b17609676c3a7a8046 (diff)
downloadbusybox-website-cc7de179d4c2160022e170a2aa7f0282d18c28fa.tar.gz
busybox-website-cc7de179d4c2160022e170a2aa7f0282d18c28fa.tar.bz2
FAQ.html: regularize capitalization of "Busybox"
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
-rw-r--r--FAQ.html341
1 files changed, 170 insertions, 171 deletions
diff --git a/FAQ.html b/FAQ.html
index 50215dc..dc02735 100644
--- a/FAQ.html
+++ b/FAQ.html
@@ -3,56 +3,56 @@
<h3>Frequently Asked Questions</h3>
This is a collection of some of the more frequently asked questions
-about BusyBox. Some of the questions even have answers. If you
+about Busybox. Some of the questions even have answers. If you
have additions to this FAQ document, we would love to add them,
<h2>General questions</h2>
<ol>
-<li><a href="#whatis">What is BusyBox?</a></li>
-<li><a href="#getting_started">How can I get started using BusyBox?</a></li>
-<li><a href="#configure">How do I configure busybox?</a></li>
-<li><a href="#build">How do I build BusyBox with a cross-compiler?</a></li>
-<li><a href="#build_system">How do I build a BusyBox-based system?</a></li>
+<li><a href="#whatis">What is Busybox?</a></li>
+<li><a href="#getting_started">How can I get started using Busybox?</a></li>
+<li><a href="#configure">How do I configure Busybox?</a></li>
+<li><a href="#build">How do I build Busybox with a cross-compiler?</a></li>
+<li><a href="#build_system">How do I build a Busybox-based system?</a></li>
<li><a href="#kernel">Which Linux kernel versions are supported?</a></li>
-<li><a href="#arch">Which architectures does BusyBox run on?</a></li>
+<li><a href="#arch">Which architectures does Busybox run on?</a></li>
<li><a href="#libc">Which C libraries are supported?</a></li>
-<li><a href="#external">Where can I find other small utilities since busybox does not include the features I want?</a></li>
+<li><a href="#external">Where can I find other small utilities since Busybox does not include the features I want?</a></li>
<li><a href="#demanding">I demand that you to add &lt;favorite feature&gt; right now! How come you don't answer all my questions on the mailing list instantly? I demand that you help me with all of my problems <em>Right Now</em>!</a></li>
-<li><a href="#helpme">I need help with BusyBox! What should I do?</a></li>
-<li><a href="#contracts">I need you to add &lt;favorite feature&gt;! Are the BusyBox developers willing to be paid in order to fix bugs or add in &lt;favorite feature&gt;? Are you willing to provide support contracts?</a></li>
-<li><a href="#commercial">Can I include BusyBox as part of the software on my device?</a></li>
-<li><a href="#commercial_use">I want to use BusyBox as part of the Linux-based firmware for a new device. Will it create any license issues in future?</a></li>
+<li><a href="#helpme">I need help with Busybox! What should I do?</a></li>
+<li><a href="#contracts">I need you to add &lt;favorite feature&gt;! Are the Busybox developers willing to be paid in order to fix bugs or add in &lt;favorite feature&gt;? Are you willing to provide support contracts?</a></li>
+<li><a href="#commercial">Can I include Busybox as part of the software on my device?</a></li>
+<li><a href="#commercial_use">I want to use Busybox as part of the Linux-based firmware for a new device. Will it create any license issues in future?</a></li>
</ol>
<h2>Troubleshooting</h2>
<ol>
-<li><a href="#bugs">I think I found a bug in BusyBox! What should I do?!</a></li>
+<li><a href="#bugs">I think I found a bug in Busybox! What should I do?!</a></li>
<li><a href="#backporting">I'm using an ancient version from the dawn of time and something's broken. Can you backport fixes for free?</a></li>
<li><a href="#init">Busybox init isn't working!</a></li>
-<li><a href="#sed">I can't configure busybox on my system.</a></li>
+<li><a href="#sed">I can't configure Busybox on my system.</a></li>
<li><a href="#job_control">Why do I keep getting "sh: can't access tty; job control turned off" errors? Why doesn't Control-C work within my shell?</a></li>
<li><a href="#touch_config">sed "/CONFIG_FOO/s/.*/CONFIG_FOO=y/" -i .config; make; does not enable applet foo</a></li>
-<li><a href="#symlink_danger">I installed a package on my busybox system and now nothing works!</a></li>
+<li><a href="#symlink_danger">I installed a package on my Busybox system and now nothing works!</a></li>
</ol>
<h2>Misc. questions</h2>
<ol>
- <li><a href="#tz">How do I change the time zone in busybox?</a></li>
+ <li><a href="#tz">How do I change the time zone in Busybox?</a></li>
</ol>
<h2>Programming questions</h2>
<ol>
- <li><a href="#goals">What are the goals of busybox?</a></li>
- <li><a href="#design">What is the design of busybox?</a></li>
+ <li><a href="#goals">What are the goals of Busybox?</a></li>
+ <li><a href="#design">What is the design of Busybox?</a></li>
<li><a href="#source">How is the source code organized?</a>
<ul>
<li><a href="#source_applets">The applet directories</a></li>
- <li><a href="#source_libbb">The busybox shared library (libbb)</a></li>
+ <li><a href="#source_libbb">The Busybox shared library (libbb)</a></li>
</ul>
</li>
- <li><a href="#optimize">I want to make busybox even smaller, how do I go about it?</a></li>
- <li><a href="#adding">Adding an applet to busybox</a></li>
- <li><a href="#standards">What standards does busybox adhere to?</a></li>
+ <li><a href="#optimize">I want to make Busybox even smaller, how do I go about it?</a></li>
+ <li><a href="#adding">Adding an applet to Busybox</a></li>
+ <li><a href="#standards">What standards does Busybox adhere to?</a></li>
<li><a href="#portability">Portability.</a></li>
<li><a href="#tips">Tips and tricks.</a>
<ul>
@@ -63,7 +63,7 @@ have additions to this FAQ document, we would love to add them,
<li><a href="#tips_kernel_headers">Including Linux kernel headers.</a></li>
</ul>
</li>
- <li><a href="#who">Who are the BusyBox developers?</a></li>
+ <li><a href="#who">Who are the Busybox developers?</a></li>
</ol>
@@ -71,9 +71,9 @@ have additions to this FAQ document, we would love to add them,
<h1>General questions</h1>
<hr />
-<h2><a name="whatis">What is BusyBox?</a></h2>
+<h2><a name="whatis">What is Busybox?</a></h2>
-<p> "I use Foomatic-9000 modem. In my modem, BusyBox v1.23.4 is installed.
+<p> "I use Foomatic-9000 modem. In my modem, Busybox v1.23.4 is installed.
I can reach my modem's Telnet interface and I can reach shell prompt.
I want to change configuration, and add some tools. Can I enable FTP?
SCP? If I edit a file on the device, I can't save it, I get
@@ -81,24 +81,24 @@ have additions to this FAQ document, we would love to add them,
</p>
<p> Questions like the example above is a sign that the person asking it
- does not fully understand what BusyBox is. BusyBox is not a complete
+ does not fully understand what Busybox is. Busybox is not a complete
solution for running modems, or wireless access points, etc.
- BusyBox is only a set of programs. Even though it is a fairly
+ Busybox is only a set of programs. Even though it is a fairly
comprehensive set of programs needed to run a Linux system, these
programs per se can not "run a modem".
</p>
-<p> In order to make BusyBox-based system useful, developers of this system
+<p> In order to make Busybox-based system useful, developers of this system
add their own parts. At the very least, there are some shell scripts
and configuration files, which control which tools are to be run,
when, and how.
Often, there are also some web pages and CGI scripts (in order
to implement web-based configuration). Also, often developers add
- other tools beside Linux kernel and BusyBox.
+ other tools beside Linux kernel and Busybox.
</p>
<p> Since these scripts, configuration files and other tools are
- custom-designed for a specific device, BusyBox mailing list is usually
+ custom-designed for a specific device, Busybox mailing list is usually
a wrong place to ask about inner workings of such a device.
You are better off googling for a forum where users of this particular
device discuss their findings about inner workings of the device,
@@ -106,40 +106,40 @@ have additions to this FAQ document, we would love to add them,
</p>
<hr />
-<h2><a name="getting_started">How can I get started using BusyBox?</a></h2>
+<h2><a name="getting_started">How can I get started using Busybox?</a></h2>
-<p> If you just want to try out busybox without installing it, download the
+<p> If you just want to try out Busybox without installing it, download the
tarball, extract it, run "make defconfig", and then run "make".
</p>
<p>
- This will create a busybox binary with almost all features enabled. To try
- out a busybox applet, type "./busybox [appletname] [options]", for
+ This will create a Busybox binary with almost all features enabled. To try
+ out a Busybox applet, type "./busybox [appletname] [options]", for
example "./busybox ls -l" or "./busybox cat LICENSE". Type "./busybox"
to see a command list, and "./busybox appletname --help" to see a brief
usage message for a given applet.
</p>
<p>
- BusyBox uses the name it was invoked under to determine which applet is
- being invoked. (Try "mv busybox ls" and then "./ls -l".) Installing
- busybox consists of creating symlinks (or hardlinks) to the busybox
- binary for each applet in busybox, and making sure these links are in
- the shell's command $PATH. The special applet name "busybox" (or with
- any optional suffix, such as "busybox-static") uses the first argument
+ Busybox uses the name it was invoked under to determine which applet is
+ being invoked. (Try "mv Busybox ls" and then "./ls -l".) Installing
+ Busybox consists of creating symlinks (or hardlinks) to the Busybox
+ binary for each applet in Busybox, and making sure these links are in
+ the shell's command $PATH. The special applet name "Busybox" (or with
+ any optional suffix, such as "Busybox-static") uses the first argument
to determine which applet to run, as shown above.
</p>
<p>
- BusyBox also has a feature called the
- <a name="standalone_shell">"standalone shell"</a>, where the busybox
+ Busybox also has a feature called the
+ <a name="standalone_shell">"standalone shell"</a>, where the Busybox
shell runs any built-in applets before checking the command path. This
feature is also enabled by "make allyesconfig", and to try it out run
the command line "PATH= ./busybox ash". This will blank your command path
- and run busybox as your command shell, so the only commands it can find
- (without an explicit path such as /bin/ls) are the built-in busybox ones.
- This is another good way to see what's built into busybox.
+ and run Busybox as your command shell, so the only commands it can find
+ (without an explicit path such as /bin/ls) are the built-in Busybox ones.
+ This is another good way to see what's built into Busybox.
Note that the standalone shell requires CONFIG_BUSYBOX_EXEC_PATH
to be set appropriately, depending on whether or not /proc/self/exe is
available or not. If you do not have /proc, then point that config option
- to the location of your busybox binary, usually /bin/busybox.
+ to the location of your Busybox binary, usually /bin/busybox.
(So if you set it to /proc/self/exe, and happen to be able to chroot into
your rootfs, you must mount /proc beforehand.)
</p>
@@ -188,32 +188,32 @@ $ echo $PATH
</pre>
<hr />
-<h2><a name="configure">How do I configure busybox?</a></h2>
+<h2><a name="configure">How do I configure Busybox?</a></h2>
<p> Busybox is configured similarly to the linux kernel. Create a default
configuration and then run "make menuconfig" to modify it. The end
- result is a .config file that tells the busybox build process what features
+ result is a .config file that tells the Busybox build process what features
to include. So instead of "./configure; make; make install" the equivalent
- busybox build would be "make defconfig; make; make install".
+ Busybox build would be "make defconfig; make; make install".
</p>
<p> Busybox configured with all features enabled is a little under a megabyte
- dynamically linked on x86. To create a smaller busybox, configure it with
- fewer features. Individual busybox applets cost anywhere from a few
+ dynamically linked on x86. To create a smaller Busybox, configure it with
+ fewer features. Individual Busybox applets cost anywhere from a few
hundred bytes to tens of kilobytes. Disable unneeded applets to save
space, using menuconfig.
</p>
-<p>The most important busybox configurators are:</p>
+<p>The most important Busybox configurators are:</p>
<ul>
<li><p>make <b>defconfig</b> - Create the maximum "sane" configuration. This
enables almost all features, minus things like debugging options and features
that require changes to the rest of the system to work (such as selinux or
devfs device names). Use this if you want to start from a full-featured
-busybox and remove features until it's small enough.</p></li>
+Busybox and remove features until it's small enough.</p></li>
<li><p>make <b>allnoconfig</b> - Disable everything. This creates a tiny version
-of busybox that doesn't do anything. Start here if you know exactly what
+of Busybox that doesn't do anything. Start here if you know exactly what
you want and would like to select only those features.</p></li>
<li><p>make <b>menuconfig</b> - Interactively modify a .config file through a
multi-level menu interface. Use this after one of the previous two.</p></li>
@@ -222,29 +222,29 @@ multi-level menu interface. Use this after one of the previous two.</p></li>
<p>Some other configuration options are:</p>
<ul>
<li><p>make <b>oldconfig</b> - Update an old .config file for a newer version
-of busybox.</p></li>
+of Busybox.</p></li>
<li><p>make <b>allyesconfig</b> - Select absolutely everything. This creates
-a statically linked version of busybox full of debug code, with dependencies on
+a statically linked version of Busybox full of debug code, with dependencies on
selinux, using devfs names... This makes sure everything compiles. Whether
or not the result would do anything useful is an open question.</p></li>
<li><p>make <b>randconfig</b> - Create a random configuration for test purposes.</p></li>
</ul>
<p> Menuconfig modifies your .config file through an interactive menu where you can enable or disable
- busybox features, and get help about each feature.
+ Busybox features, and get help about each feature.
<p>
- To build a smaller busybox binary, run "make menuconfig" and disable the
+ To build a smaller Busybox binary, run "make menuconfig" and disable the
features you don't need. (Or run "make allnoconfig" and then use
menuconfig to add just the features you need. Don't forget to recompile
with "make" once you've finished configuring.)
</p>
<hr />
-<h2><a name="build">How do I build BusyBox with a cross-compiler?</a></h2>
+<h2><a name="build">How do I build Busybox with a cross-compiler?</a></h2>
<p>
- To build busybox with a cross-compiler, specify CROSS_COMPILE=&lt;prefix&gt;.
+ To build Busybox with a cross-compiler, specify CROSS_COMPILE=&lt;prefix&gt;.
</p>
<p>
CROSS_COMPILE specifies the prefix used for all executables used
@@ -265,7 +265,7 @@ or not the result would do anything useful is an open question.</p></li>
editing the .config file.
</p>
<p>
- Example: here's the script which donloads and compiles busybox
+ Example: here's the script which donloads and compiles Busybox
using Rob's toolchain from Aboriginal Linux:
<pre>
#!/bin/sh
@@ -276,14 +276,14 @@ test -f cross-compiler-armv5l.tar.bz2 \
rm -rf cross-compiler-armv5l
tar xf cross-compiler-armv5l.tar.bz2
-test -f busybox-1.17.2.tar.bz2 \
+test -f Busybox-1.17.2.tar.bz2 \
|| wget http://busybox.net/downloads/busybox-1.17.2.tar.bz2
-rm -rf busybox-1.17.2
-tar xf busybox-1.17.2.tar.bz2
+rm -rf Busybox-1.17.2
+tar xf Busybox-1.17.2.tar.bz2
CROSS_COMPILE="$PWD/cross-compiler-armv5l/bin/armv5l-"
-cd busybox-1.17.2
+cd Busybox-1.17.2
make CROSS_COMPILE="$CROSS_COMPILE" defconfig
make CROSS_COMPILE="$CROSS_COMPILE"
</pre>
@@ -291,10 +291,10 @@ make CROSS_COMPILE="$CROSS_COMPILE"
<hr />
-<h2><a name="build_system">How do I build a BusyBox-based system?</a></h2>
+<h2><a name="build_system">How do I build a Busybox-based system?</a></h2>
<p>
- BusyBox is a package that replaces a dozen standard packages, but it is
+ Busybox is a package that replaces a dozen standard packages, but it is
not by itself a complete bootable system. Building an entire Linux
distribution from source is a bit beyond the scope of this FAQ, but it
understandably keeps cropping up on the mailing list, so here are some
@@ -321,11 +321,11 @@ make CROSS_COMPILE="$CROSS_COMPILE"
Beyond Linux From Scratch, Hardened Linux From Scratch, their Hints
directory, and their LiveCD project. (They also have mailing lists which
are better sources of answers to Linux-system building questions than
- the busybox list.)
+ the Busybox list.)
</p>
<p>
If you want an automated yet customizable system builder which produces
- a BusyBox and uClibc based system, try
+ a Busybox and uClibc based system, try
<a href="http://buildroot.uclibc.org/">buildroot</a>, which is
another project by the maintainer of the uClibc (Erik Andersen).
Download the tarball, extract it, unset CC, make.
@@ -345,10 +345,10 @@ make CROSS_COMPILE="$CROSS_COMPILE"
</p>
<hr />
-<h2><a name="arch">Which architectures does BusyBox run on?</a></h2>
+<h2><a name="arch">Which architectures does Busybox run on?</a></h2>
<p>
- BusyBox in general will build on any architecture supported by gcc.
+ Busybox in general will build on any architecture supported by gcc.
Kernel module loading for 2.4 Linux kernels is currently
limited to ARM, CRIS, H8/300, x86, ia64, x86_64, m68k, MIPS, PowerPC,
S390, SH3/4/5, Sparc, v850e, and x86_64 for 2.4.x kernels.
@@ -361,25 +361,25 @@ make CROSS_COMPILE="$CROSS_COMPILE"
<h2><a name="libc">Which C libraries are supported?</a></h2>
<p>
- On Linux, BusyBox releases are tested against uClibc (0.9.27 or later) and
- glibc (2.2 or later). Both should provide full functionality with busybox,
+ On Linux, Busybox releases are tested against uClibc (0.9.27 or later) and
+ glibc (2.2 or later). Both should provide full functionality with Busybox,
and if you find a bug we want to hear about it.
</p>
<p>
Linux-libc5 is no longer maintained (and has no known advantages over
uClibc), dietlibc is known to have numerous unfixed bugs, and klibc is
- missing too many features to build BusyBox. If you require a small C
- library for Linux, the busybox developers recommend uClibc.
+ missing too many features to build Busybox. If you require a small C
+ library for Linux, the Busybox developers recommend uClibc.
</p>
<p>
- Some BusyBox applets have been built and run under a combination
+ Some Busybox applets have been built and run under a combination
of newlib and libgloss (see
<a href="http://www.busybox.net/lists/busybox/2005-March/013759.html">this thread</a>).
This is still experimental, but may be supported in a future release.
</p>
<hr />
-<h2><a name="external">Where can I find other small utilities since busybox
+<h2><a name="external">Where can I find other small utilities since Busybox
does not include the features i want?</a></h2>
<p>
@@ -391,20 +391,20 @@ make CROSS_COMPILE="$CROSS_COMPILE"
<p>
You have not paid us a single cent and yet you still have the product of
- many years of our work. We are not your slaves! We work on BusyBox
+ many years of our work. We are not your slaves! We work on Busybox
because we find it useful and interesting. If you go off flaming us, we
will ignore you.
<hr />
-<h2><a name="helpme">I need help with BusyBox! What should I do?</a></h2>
+<h2><a name="helpme">I need help with Busybox! What should I do?</a></h2>
<p>
- If you find that you need help with BusyBox, you can ask for help on the
- BusyBox mailing list at busybox@busybox.net.</p>
+ If you find that you need help with Busybox, you can ask for help on the
+ Busybox mailing list at busybox@busybox.net.</p>
<p> In addition to the mailing list, Erik Andersen (andersee), Manuel Nova
(mjn3), Rob Landley (landley), Mike Frysinger (SpanKY),
- Bernhard Reutner-Fischer (blindvt), and other long-time BusyBox developers
+ Bernhard Reutner-Fischer (blindvt), and other long-time Busybox developers
are known to hang out on the uClibc IRC channel: #uclibc on
irc.freenode.net. There is a
<a href="http://ibot.Rikers.org/%23uclibc/">web archive of
@@ -413,21 +413,21 @@ make CROSS_COMPILE="$CROSS_COMPILE"
<p>
<b>Please do not send private email to Rob, Erik, Manuel, or the other
- BusyBox contributors asking for private help unless you are planning on
+ Busybox contributors asking for private help unless you are planning on
paying for consulting services.</b>
</p>
<p>
- When we answer questions on the BusyBox mailing list, it helps everyone
+ When we answer questions on the Busybox mailing list, it helps everyone
since people with similar problems in the future will be able to get help
by searching the mailing list archives. Private help is reserved as a paid
service. If you need to use private communication, or if you are serious
- about getting timely assistance with BusyBox, you should seriously consider
+ about getting timely assistance with Busybox, you should seriously consider
paying for consulting services.
</p>
<hr />
-<h2><a name="contracts">I need you to add &lt;favorite feature&gt;! Are the BusyBox developers willing to be paid in order to fix bugs or add in &lt;favorite feature&gt;? Are you willing to provide support contracts?</a></h2>
+<h2><a name="contracts">I need you to add &lt;favorite feature&gt;! Are the Busybox developers willing to be paid in order to fix bugs or add in &lt;favorite feature&gt;? Are you willing to provide support contracts?</a></h2>
<p>
Yes we are. The easy way to sponsor a new feature is to post an offer on
@@ -436,22 +436,22 @@ make CROSS_COMPILE="$CROSS_COMPILE"
</p>
<hr />
-<h2><a name="commercial">Can I include BusyBox as part of the software on my device?</a></h2>
+<h2><a name="commercial">Can I include Busybox as part of the software on my device?</a></h2>
<p>
Yes. As long as you <a href="http://busybox.net/license.html">fully comply
- with the terms of the GPL BusyBox license</a> you can ship BusyBox
+ with the terms of the GPL Busybox license</a> you can ship Busybox
as part of the software on your device.
</p>
<hr />
-<h2><a name="commercial_use">I want to use BusyBox as part of the Linux-based firmware for a new device. Will it create any license issues in future?</a></h2>
+<h2><a name="commercial_use">I want to use Busybox as part of the Linux-based firmware for a new device. Will it create any license issues in future?</a></h2>
<p>
-If you use busybox binary in your device's firmware, and if you
+If you use Busybox binary in your device's firmware, and if you
(or the company you work for) is providing this device to others
(selling, giving for free, etc), you have to provide users
-with means to build the same busybox binary from source.
+with means to build the same Busybox binary from source.
<p>
For example, you may do it by placing the following, or similar,
text somewhere on the company's web site:
@@ -460,8 +460,8 @@ text somewhere on the company's web site:
This device's firmware includes the following open-source components:<br>
...<br>
...<br>
- BusyBox:<br>
- We are using patched version of busybox 1.6.2.<br>
+ Busybox:<br>
+ We are using patched version of Busybox 1.6.2.<br>
In order to rebuild it from source, download<br>
http://company.site.com/firmware/source/busybox-1.6.2.tar.gz,<br>
unpack it to an empty directory,<br>
@@ -470,11 +470,11 @@ text somewhere on the company's web site:
and<br>
http://company.site.com/firmware/source/.config<br>
to the same directory and apply the patch with this command:<br>
- patch -p1 &lt;busybox-1.6.2.patch<br>
- Now you can build busybox with these commands:<br>
+ patch -p1 &lt;Busybox-1.6.2.patch<br>
+ Now you can build Busybox with these commands:<br>
export ARCH=arm<br>
make CROSS_COMPILE=arm-linux-uclibc-<br>
- After successful build, you will have busybox binary<br>
+ After successful build, you will have Busybox binary<br>
in this directory.<br>
If make command fails with the message<br>
"arm-linux-uclibc-gcc: command not found"<br>
@@ -494,15 +494,15 @@ binary firmware images.
If you want to be extra nice, you may provide URLs to places
where people may get ARM toolchains or read HOWTOs explaining
how to build one. You may even provide the toolchain.
-You may explain how to download newly built busybox binary
+You may explain how to download newly built Busybox binary
into the device. But these "extra nice" things are not required
by license. License also does not require you to provide
any support for users which use firmware (or part of it)
built from source.
<p>
-What license does require, though, is that busybox
+What license does require, though, is that Busybox
source which you provide actually can be built and that
-it will match busybox binary which is found in your binary firmware.
+it will match Busybox binary which is found in your binary firmware.
Match is meant as "functional match", not byte-by-byte match -
binaries may slightly differ because of different compilers/linkers used.
</p>
@@ -511,25 +511,25 @@ binaries may slightly differ because of different compilers/linkers used.
<h1>Troubleshooting</h1>
<hr />
-<h2><a name="bugs">I think I found a bug in BusyBox! What should I do?</a></h2>
+<h2><a name="bugs">I think I found a bug in Busybox! What should I do?</a></h2>
<p>
- If you simply need help with using or configuring BusyBox, please submit a
- detailed description of your problem to the BusyBox mailing list at <a
+ If you simply need help with using or configuring Busybox, please submit a
+ detailed description of your problem to the Busybox mailing list at <a
href="mailto:busybox@busybox.net">busybox@busybox.net</a>.
Please do not send email to individual developers asking
for private help unless you are planning on paying for consulting services.
- When we answer questions on the BusyBox mailing list, it helps everyone,
+ When we answer questions on the Busybox mailing list, it helps everyone,
while private answers help only you...
</p>
<p>
Bug reports and new feature patches sometimes get lost when posted to the
- mailing list, because the developers of BusyBox are busy people and have
+ mailing list, because the developers of Busybox are busy people and have
only so much they can keep in their brains at a time. You can post a
polite reminder after 2-3 days without offending anybody. If that doesn't
result in a solution, please use the
- <a href="https://bugs.busybox.net/">BusyBox Bug
+ <a href="https://bugs.busybox.net/">Busybox Bug
and Patch Tracking System</a> to submit a detailed explanation and we'll
get to it as soon as we can.
</p>
@@ -551,12 +551,12 @@ binaries may slightly differ because of different compilers/linkers used.
<p>If you see a bug in an old version, it is recommended that you first check
whether the problem still exists in the most recent release.</p>
-<p>The purpose of the BusyBox mailing list is to develop and improve BusyBox,
+<p>The purpose of the Busybox mailing list is to develop and improve Busybox,
and we're happy to respond to our users' needs. But if you're coming to the
list for free tech support we're going to ask you to upgrade to a current
version before we try to diagnose your problem.</p>
-<p>If you're building BusyBox 0.50 with uClibc 0.9.19 and gcc 1.27 there's a
+<p>If you're building Busybox 0.50 with uClibc 0.9.19 and gcc 1.27 there's a
fairly large chance that whatever problem you're seeing has already been fixed.
To get that fix, all you have to do is upgrade to a newer version. If you
don't at least _try_ that, you're wasting our time.</p>
@@ -566,12 +566,12 @@ versions, you can employ this trick:</p>
<p>Download most recent release, configure it with "make allnoconfig", then
use menuconfig to switch on just the applet you want to test and maybe
-a couple of tuning options. Then build busybox.</p>
+a couple of tuning options. Then build Busybox.</p>
<p>Then, on target system, delete the old applet symlink that points
-to your old busybox, and replace it with the new busybox binary, renamed
+to your old Busybox, and replace it with the new Busybox binary, renamed
to applet's name. In other words, if you want to replace only, say, httpd,
-then delete, say, /bin/httpd symlink (which points to your old busybox),
+then delete, say, /bin/httpd symlink (which points to your old Busybox),
then run "cp /path/to/new/busybox /bin/httpd". For some applets, you'll
also need to "chmod u+s" it.</p>
@@ -580,7 +580,7 @@ list, either "I see such and such bug even in latest release" or "I see such
and such bug in release X.Y.Z, but it seems to be fixed in last release".</p>
<p>Deleting the old symlink still leaves the old functionality in your existing
-old busybox binary, you just wouldn't be using it anymore. If things will
+old Busybox binary, you just wouldn't be using it anymore. If things will
get even worse with new version, you can always restore the symlink.</p>
<p>The volunteers are happy to fix any bugs you point out in the current
@@ -631,40 +631,40 @@ int main(int argc, char *argv)
<p>
Now try to boot your device with an "init=" argument pointing to your
hello world program. Did you see the hello world message? Until you
- do, don't bother messing with busybox init.
+ do, don't bother messing with Busybox init.
</p>
<p>
Once you've got it working statically linked, try getting it to work
dynamically linked. Then read the FAQ entry <a href="#build_system">How
- do I build a BusyBox-based system?</a>, and the
- <a href="/downloads/BusyBox.html#item_init">documentation for BusyBox
+ do I build a Busybox-based system?</a>, and the
+ <a href="/downloads/busybox.html#item_init">documentation for Busybox
init</a>.
</p>
<hr />
-<h2><a name="sed">I can't configure busybox on my system.</a></h2>
+<h2><a name="sed">I can't configure Busybox on my system.</a></h2>
<p>
Configuring Busybox depends on a recent version of sed. Older
distributions (Red Hat 7.2, Debian 3.0) may not come with a
- usable version. Luckily BusyBox can use its own sed to configure itself,
+ usable version. Luckily Busybox can use its own sed to configure itself,
although this leads to a bit of a chicken and egg problem.
- You can work around this by hand-configuring busybox to build with just
- sed, then putting that sed in your path to configure the rest of busybox
+ You can work around this by hand-configuring Busybox to build with just
+ sed, then putting that sed in your path to configure the rest of Busybox
with, like so:
</p>
<pre>
tar xvjf sources/busybox-x.x.x.tar.bz2
- cd busybox-x.x.x
+ cd Busybox-x.x.x
make allnoconfig
make include/bb_config.h
echo "CONFIG_SED=y" >> .config
echo "#undef ENABLE_SED" >> include/bb_config.h
echo "#define ENABLE_SED 1" >> include/bb_config.h
make
- mv busybox sed
+ mv Busybox sed
export PATH=`pwd`:"$PATH"
</pre>
@@ -743,7 +743,7 @@ int main(int argc, char *argv)
In some common cases like "make allnoconfig", both .config and dependent
generated files are updated, making their mtimes very close. If you have
a build script which modifies .config immediately after this,
- and then rebuilds the busybox, it may happen that .config's mtime will be
+ and then rebuilds the Busybox, it may happen that .config's mtime will be
still close the the generated files' mtimes. If filesystem
time granularity is low (for example, 1 second), these mtimes may end up
being equal, and dependent files wouldn't be rebuilt. The work around
@@ -751,7 +751,7 @@ int main(int argc, char *argv)
</p>
<hr />
-<h2><a name="symlink_danger">I installed a package on my busybox system and now nothing works!</a></h2>
+<h2><a name="symlink_danger">I installed a package on my Busybox system and now nothing works!</a></h2>
<p>
"The system boots fine, but when I compile the latest e2fsprogs from sourceforge
@@ -760,7 +760,7 @@ int main(int argc, char *argv)
<p>
If /sbin/tune2fs is a link to /bin/busybox and e2fsprogs install process
overwrites it instead of deleting it and then creating new /sbin/tune2fs
- executable, then /bin/busybox is not a busybox binary anymore, it is
+ executable, then /bin/busybox is not a Busybox binary anymore, it is
a tune2fs binary. ALL /[s]bin/xxxx -> /bin/busybox links now point to it,
including /sbin/init. When kernel runs /sbin/init, it runs tune2fs, which
prints help text and exits.
@@ -770,7 +770,7 @@ int main(int argc, char *argv)
<h1>Misc. questions</h1>
<hr />
-<h2><a name="tz">How do I change the time zone in busybox?</a></h2>
+<h2><a name="tz">How do I change the time zone in Busybox?</a></h2>
<p>Busybox has nothing to do with the timezone. Please consult your libc
documentation. (<a href="http://google.com/search?q=uclibc+glibc+timezone">http://google.com/search?q=uclibc+glibc+timezone</a>).</p>
@@ -779,7 +779,7 @@ documentation. (<a href="http://google.com/search?q=uclibc+glibc+timezone">http:
<h1>Development</h1>
<hr />
-<h2><a name="goals">What are the goals of busybox?</a></h2>
+<h2><a name="goals">What are the goals of Busybox?</a></h2>
<p>Busybox aims to be the smallest and simplest correct implementation of the
standard Linux command line tools. First and foremost, this means the
@@ -789,25 +789,25 @@ compliant</a>, minimize run-time memory usage (heap and stack), run fast, and
take over the world.</p>
<hr />
-<h2><a name="design">What is the design of busybox?</a></h2>
+<h2><a name="design">What is the design of Busybox?</a></h2>
<p>Busybox is like a swiss army knife: one thing with many functions.
-The busybox executable can act like many different programs depending on
+The Busybox executable can act like many different programs depending on
the name used to invoke it. Normal practice is to create a bunch of symlinks
-pointing to the busybox binary, each of which triggers a different busybox
+pointing to the Busybox binary, each of which triggers a different Busybox
function. (See <a href="FAQ.html#getting_started">getting started</a> in the
-FAQ for more information on usage, and <a href="BusyBox.html">the
-busybox documentation</a> for a list of symlink names and what they do.)
+FAQ for more information on usage, and <a href="Busybox.html">the
+Busybox documentation</a> for a list of symlink names and what they do.)
<p>The "one binary to rule them all" approach is primarily for size reasons: a
single multi-purpose executable is smaller then many small files could be.
-This way busybox only has one set of ELF headers, it can easily share code
+This way Busybox only has one set of ELF headers, it can easily share code
between different apps even when statically linked, it has better packing
efficiency by avoding gaps between files or compression dictionary resets,
and so on.</p>
<p>Work is underway on new options such as "make standalone" to build separate
-binaries for each applet, and a "libbb.so" to make the busybox common code
+binaries for each applet, and a "libbb.so" to make the Busybox common code
available as a shared library. Neither is ready yet at the time of this
writing.</p>
@@ -816,8 +816,8 @@ writing.</p>
<hr />
<h2><a name="source_applets">The applet directories</a></h2>
-<p>The directory "applets" contains the busybox startup code (applets.c and
-busybox.c), and several subdirectories containing the code for the individual
+<p>The directory "applets" contains the Busybox startup code (applets.c and
+Busybox.c), and several subdirectories containing the code for the individual
applets.</p>
<p>Busybox execution starts with the main() function in applets/busybox.c,
@@ -827,12 +827,12 @@ run_applet_and_exit() in applets/applets.c. That uses the applets[] array
transfer control to the appropriate APPLET_main() function (such as
cat_main() or sed_main()). The individual applet takes it from there.</p>
-<p>This is why calling busybox under a different name triggers different
+<p>This is why calling Busybox under a different name triggers different
functionality: main() looks up argv[0] in applets[] to get a function pointer
to APPLET_main().</p>
<p>Busybox applets may also be invoked through the multiplexor applet
-"busybox" (see busybox_main() in libbb/appletlib.c), and through the
+"Busybox" (see Busybox_main() in libbb/appletlib.c), and through the
standalone shell (grep for STANDALONE_SHELL in applets/shell/*.c).
See <a href="FAQ.html#getting_started">getting started</a> in the
FAQ for more information on these alternate usage mechanisms, which are
@@ -849,17 +849,17 @@ subdirectory.</p>
<p>The run-time --help is stored in usage_messages[], which is initialized at
the start of applets/applets.c and gets its help text from usage.h. During the
-build this help text is also used to generate the BusyBox documentation (in
+build this help text is also used to generate the Busybox documentation (in
html, txt, and man page formats) in the docs directory. See
-<a href="#adding">adding an applet to busybox</a> for more
+<a href="#adding">adding an applet to Busybox</a> for more
information.</p>
<hr />
<h2><a name="source_libbb"><b>libbb</b></a></h2>
-<p>Most non-setup code shared between busybox applets lives in the libbb
+<p>Most non-setup code shared between Busybox applets lives in the libbb
directory. It's a mess that evolved over the years without much auditing
-or cleanup. For anybody looking for a great project to break into busybox
+or cleanup. For anybody looking for a great project to break into Busybox
development with, documenting libbb would be both incredibly useful and good
experience.</p>
@@ -871,7 +871,7 @@ and/or retry automatically, linked list management functions (llist.c),
command line argument parsing (getopt32.c), and a whole lot more.</p>
<hr />
-<h2><a name="optimize">I want to make busybox even smaller, how do I go about it?</a></h2>
+<h2><a name="optimize">I want to make Busybox even smaller, how do I go about it?</a></h2>
<p>
To conserve bytes it's good to know where they're being used, and the
@@ -881,17 +881,17 @@ command line argument parsing (getopt32.c), and a whole lot more.</p>
savings add up).
</p>
-<p> The busybox Makefile builds two versions of busybox, one of which
- (busybox_unstripped) has extra information that various analysis tools
+<p> The Busybox Makefile builds two versions of Busybox, one of which
+ (Busybox_unstripped) has extra information that various analysis tools
can use. (This has nothing to do with CONFIG_DEBUG, leave that off
when trying to optimize for size.)
</p>
<p> The <b>"make bloatcheck"</b> option uses Matt Mackall's bloat-o-meter
- script to compare two versions of busybox (busybox_unstripped vs
- busybox_old), and report which symbols changed size and by how much.
+ script to compare two versions of Busybox (Busybox_unstripped vs
+ Busybox_old), and report which symbols changed size and by how much.
To use it, first build a base version with <b>"make baseline"</b>.
- (This creates busybox_old, which should have the original sizes for
+ (This creates Busybox_old, which should have the original sizes for
comparison purposes.) Then build the new version with your changes
and run "make bloatcheck" to see the size differences from the old
version.
@@ -906,12 +906,12 @@ command line argument parsing (getopt32.c), and a whole lot more.</p>
</p>
<p>
The <b>"make sizes"</b> option produces raw symbol size information for
- busybox_unstripped. This is the output from the "nm --size-sort"
+ Busybox_unstripped. This is the output from the "nm --size-sort"
command (see "man nm" for more information), and is the information
bloat-o-meter parses to produce the comparison report above. For
defconfig, this is a good way to find the largest symbols in the tree
(which is a good place to start when trying to shrink the code). To
- take a closer look at individual applets, configure busybox with just
+ take a closer look at individual applets, configure Busybox with just
one applet (run "make allnoconfig" and then switch on a single applet
with menuconfig), and then use "make sizes" to see the size of that
applet's components.
@@ -919,19 +919,19 @@ command line argument parsing (getopt32.c), and a whole lot more.</p>
<p>
The "showasm" command (in the scripts directory) produces an assembly
dump of a function, providing a closer look at what changed. Try
- "scripts/showasm busybox_unstripped" to list available symbols, and
- "scripts/showasm busybox_unstripped symbolname" to see the assembly
+ "scripts/showasm Busybox_unstripped" to list available symbols, and
+ "scripts/showasm Busybox_unstripped symbolname" to see the assembly
for a sepecific symbol.
</p>
<hr />
-<h2><a name="adding">Adding an applet to busybox</a></h2>
+<h2><a name="adding">Adding an applet to Busybox</a></h2>
-<p>To add a new applet to busybox, first pick a name for the applet and
+<p>To add a new applet to Busybox, first pick a name for the applet and
a corresponding CONFIG_NAME. Then do this:</p>
<ul>
-<li>Figure out where in the busybox source tree your applet best fits,
+<li>Figure out where in the Busybox source tree your applet best fits,
and put your source code there. Be sure to use APPLET_main() instead
of main(), where APPLET is the name of your applet.</li>
@@ -950,13 +950,13 @@ won't work.)</li>
<li>Add your applet's runtime help text to "include/usage.h". You need
at least appname_trivial_usage (the minimal help text, always included
-in the busybox binary when this applet is enabled) and appname_full_usage
-(extra help text included in the busybox binary with
+in the Busybox binary when this applet is enabled) and appname_full_usage
+(extra help text included in the Busybox binary with
CONFIG_FEATURE_VERBOSE_USAGE is enabled), or it won't compile.
The other two help entry types (appname_example_usage and
appname_notes_usage) are optional. They don't take up space in the binary,
-but instead show up in the generated documentation (BusyBox.html,
-BusyBox.txt, and the man page BusyBox.1).</li>
+but instead show up in the generated documentation (Busybox.html,
+Busybox.txt, and the man page Busybox.1).</li>
<li>Run menuconfig, switch your applet on, compile, test, and fix the
bugs. Be sure to try both "allyesconfig" and "allnoconfig".</li>
@@ -964,7 +964,7 @@ bugs. Be sure to try both "allyesconfig" and "allnoconfig".</li>
</ul>
<hr />
-<h2><a name="standards">What standards does busybox adhere to?</a></h2>
+<h2><a name="standards">What standards does Busybox adhere to?</a></h2>
<p>The standard we're paying attention to is the "Shell and Utilities"
portion of the <a href="http://www.opengroup.org/onlinepubs/009695399/">Open
@@ -989,7 +989,7 @@ similar operating systems that are easy to do and won't require much
maintenance.</p>
<p>In practice, standards compliance tends to be a clean-up step once an
-applet is otherwise finished. When polishing and testing a busybox applet,
+applet is otherwise finished. When polishing and testing a Busybox applet,
we ensure we have at least the option of full standards compliance, or else
document where we (intentionally) fall short.</p>
@@ -1000,7 +1000,7 @@ document where we (intentionally) fall short.</p>
about portability. First of all, there are different hardware platforms,
different C library implementations, different versions of the kernel and
build toolchain... The file "include/platform.h" exists to centralize and
-encapsulate various platform-specific things in one place, so most busybox
+encapsulate various platform-specific things in one place, so most Busybox
code doesn't have to care where it's running.</p>
<p>To start with, Linux runs on dozens of hardware platforms. We try to test
@@ -1034,7 +1034,7 @@ we now use c99 features, although
<a href="http://fabrice.bellard.free.fr/tcc/">tcc</a> might be worth a
look.</p>
-<p>We also test busybox against the current release of uClibc. Older versions
+<p>We also test Busybox against the current release of uClibc. Older versions
of uClibc aren't very interesting (they were buggy, and uClibc wasn't really
usable as a general-purpose C library before version 0.9.26 anyway).</p>
@@ -1058,7 +1058,7 @@ emulation. Also, some embedded Linux systems run a Linux kernel but amputate
things like the /proc directory to save space.</p>
<p>Supporting these systems is largely a question of providing a clean subset
-of BusyBox's functionality -- whichever applets can easily be made to
+of Busybox's functionality -- whichever applets can easily be made to
work in that environment. Annotating the configuration system to
indicate which applets require which prerequisites (such as procfs) is
also welcome. Other efforts to support these systems (swapping #include
@@ -1073,7 +1073,7 @@ something we're trying to avoid.</p>
<hr />
<h2><a name="tips">Programming tips and tricks.</a></h2>
-<p>Various things busybox uses that aren't particularly well documented
+<p>Various things Busybox uses that aren't particularly well documented
elsewhere.</p>
<hr />
@@ -1112,7 +1112,7 @@ a specific password until they know what the salt value is.</p>
<p>The third field is the encrypted password (plus the salt). For md5 this
is 22 bytes.</p>
-<p>The busybox function to handle all this is pw_encrypt(clear, salt) in
+<p>The Busybox function to handle all this is pw_encrypt(clear, salt) in
"libbb/pw_encrypt.c". The first argument is the clear text password to be
encrypted, and the second is a string in "$type$salt$password" format, from
which the "type" and "salt" fields will be extracted to produce an encrypted
@@ -1321,7 +1321,7 @@ we don't live in a perfect world.</p>
<p>For example, Busybox's losetup code wants linux/loop.c because nothing else
#defines the structures to call the kernel's loopback device setup ioctls.
-Attempts to cut and paste the information into a local busybox header file
+Attempts to cut and paste the information into a local Busybox header file
proved incredibly painful, because portions of the loop_info structure vary by
architecture, namely the type __kernel_dev_t has different sizes on alpha,
arm, x86, and so on. Meaning we either #include &lt;linux/posix_types.h&gt; or
@@ -1338,7 +1338,7 @@ check if we're building on 2.6, and if so just use the new 64 bit structure
instead to avoid the rename entirely.) But we still need the version
check, since 2.4 didn't have the 64 bit structure.</p>
-<p>The BusyBox developers spent <u>two years</u> trying to figure
+<p>The Busybox developers spent <u>two years</u> trying to figure
out a clean way to do all this. There isn't one. The losetup in the
util-linux package from kernel.org isn't doing it cleanly either, they just
hide the ugliness by nesting #include files. Their mount/loop.h
@@ -1352,15 +1352,14 @@ way to do it. However, block copying information out of the kernel headers
is not a better way.</p>
<hr />
-<h2><a name="who">Who are the BusyBox developers?</a></h2>
+<h2><a name="who">Who are the Busybox developers?</a></h2>
<p>The following login accounts currently exist on busybox.net. (I.E. these
-people can commit <a href="http://busybox.net/downloads/patches/">patches</a>
-into the BusyBox, uClibc, and buildroot projects.)</p>
+people can commit patches into the Busybox, uClibc, and buildroot projects.)</p>
<pre>
aldot :Bernhard Reutner-Fischer
-andersen :Erik Andersen - uClibc and BuildRoot maintainer.
+andersen :Erik Andersen - uClibc and BuildRoot maintainer
bug1 :Glenn McGrath
davidm :David McCullough
gkajmowi :Garrett Kajmowicz - uClibc++ maintainer
@@ -1381,7 +1380,7 @@ solar :Ned Ludd
timr :Tim Riker
tobiasa :Tobias Anderberg
vapier :Mike Frysinger
-vda :Denys Vlasenko - BusyBox maintainer
+vda :Denys Vlasenko - Busybox maintainer
</pre>
<p>The following accounts used to exist on busybox.net, but don't anymore so