mirror of
https://github.com/sheumann/hush.git
synced 2024-11-13 14:06:21 +00:00
134 lines
5.5 KiB
Plaintext
134 lines
5.5 KiB
Plaintext
# BusyBox configuration option Help File
|
|
#
|
|
# Format of this file: description<nl>variable<nl>help text<nl><nl>.
|
|
# The help texts may contain empty lines, but every non-empty line must
|
|
# be indented two positions. Order of the help texts does not matter,
|
|
# however, no variable should be documented twice: if it is, only the
|
|
# first occurrence will be used. We try to keep the help texts of related
|
|
# variables close together. Lines starting with `#' are ignored. To be
|
|
# nice to menuconfig, limit your line length to 70 characters.
|
|
#
|
|
# Comments of the form "# Choice:" followed by a menu name are used
|
|
# internally by the maintainers' consistency-checking tools.
|
|
#
|
|
# If you add a help text to this file, please try to be as gentle as
|
|
# possible. Don't use unexplained acronyms and generally write for the
|
|
# hypothetical ignorant but intelligent user who has just bought a PC,
|
|
# removed Windows, installed Linux and is now compiling up BusyBox
|
|
# for the first time. Tell them what to do if they're unsure.
|
|
#
|
|
# Mention all the relevant READMEs and HOWTOs in the help text.
|
|
# Make them file URLs relative to the top level of the source tree so
|
|
# that help browsers can turn them into hotlinks. All URLs ahould be
|
|
# surrounded by <>.
|
|
#
|
|
# Repetitions are fine since the help texts are not meant to be read
|
|
# in sequence. It is good style to include URLs pointing to more
|
|
# detailed technical information, pictures of the hardware, etc.
|
|
#
|
|
# The most important thing to include in a help entry is *motivation*.
|
|
# Explain why someone configuring BusyBox might want to select your
|
|
# option.
|
|
#
|
|
|
|
Show verbose applets usage message
|
|
CONFIG_FEATURE_VERBOSE_USAGE
|
|
All BusyBox applets will show more verbose help messages when
|
|
busybox is invoked with --help. This will add lots of text to the
|
|
busybox binary. In the default configuration, this will add about
|
|
13k, but it can add much more depending on your configuration.
|
|
|
|
Enable automatic symlink creation for BusyBox built-in applets
|
|
CONFIG_FEATURE_INSTALLER
|
|
Enable 'busybox --install [-s]' support. This will allow you to use
|
|
busybox at runtime to create hard links or symlinks for all the
|
|
applets that are compiled into busybox. This feature requires the
|
|
/proc filesystem.
|
|
|
|
Locale support
|
|
CONFIG_LOCALE_SUPPORT
|
|
Enable this if your system has locale support, and you would like
|
|
busybox to support locale settings.
|
|
|
|
Enable devfs support
|
|
CONFIG_FEATURE_DEVFS
|
|
Enable if you want BusyBox to work with devfs.
|
|
|
|
Enable devfs support
|
|
CONFIG_FEATURE_DEVPTS
|
|
Enable if you want BusyBox to use Unix98 PTY support. If enabled,
|
|
busybox will use /dev/ptmx for the master side of the pseudoterminal
|
|
and /dev/pts/<number> for the slave side. Otherwise, BSD style
|
|
/dev/ttyp<number> will be used. To use this option, you should have
|
|
devpts or devfs mounted.
|
|
|
|
Clean up all memory before exiting
|
|
CONFIG_FEATURE_CLEAN_UP
|
|
As a size optimization, busybox by default does not cleanup memory
|
|
that is dynamically allocated or close files before exiting. This
|
|
saves space and is usually not needed since the OS will clean up for
|
|
us. Don't enable this unless you have a really good reason to clean
|
|
things up manually.
|
|
|
|
Buffers allocation policy
|
|
CONFIG_FEATURE_BUFFERS_USE_MALLOC
|
|
There are 3 ways BusyBox can handle buffer allocations:
|
|
- Use malloc. This costs code size for the call to xmalloc.
|
|
- Put them on stack. For some very small machines with limited stack
|
|
space, this can be deadly. For most folks, this works just fine.
|
|
- Put them in BSS. This works beautifully for computers with a real
|
|
MMU (and OS support), but wastes runtime RAM for uCLinux. This
|
|
behavior was the only one available for BusyBox versions 0.48 and
|
|
earlier.
|
|
|
|
Enable the ar applet
|
|
CONFIG_AR
|
|
ar is an archival utility program used to create, modify, and
|
|
extract contents from archives. An archive is a single file holding
|
|
a collection of other files in a structure that makes it possible to
|
|
retrieve the original individual files (called archive members).
|
|
The original files' contents, mode (permissions), timestamp, owner,
|
|
and group are preserved in the archive, and can be restored on
|
|
extraction.
|
|
On an x86 system, the ar applet adds about XXX bytes.
|
|
|
|
Unless you have a specific application which requires ar, you should
|
|
probably say N here.
|
|
|
|
Enable the bunzip2 applet
|
|
CONFIG_BUNZIP2
|
|
bunzip2 is an compression utility using the Burrows-Wheeler block
|
|
sorting text compression algorithm, and Huffman coding. Compression
|
|
is generally considerably better than that achieved by more
|
|
conventional LZ77/LZ78-based compressors, and approaches the
|
|
performance of the PPM family of statistical compressors.
|
|
|
|
The BusyBox bunzip2 applet is limited to de-compression only. On an
|
|
x86 system, this applet adds about XXX bytes.
|
|
|
|
Unless you have a specific application which requires bunzip2, you
|
|
should probably say N here.
|
|
|
|
# FIXME -- document the rest of the BusyBox config options....
|
|
|
|
Enable the run-parts applet
|
|
CONFIG_RUN_PARTS
|
|
run-parts is an utility designed to run all the scripts in a directory.
|
|
|
|
It is useful to set up a directory like cron.daily, where you need to
|
|
execute all the scripts in that directory.
|
|
|
|
This implementation of run-parts doesn't accept long options, and
|
|
some features (like report mode) aren't implemented.
|
|
|
|
Unless you know that run-parts is used in some of your scripts
|
|
you can safely say N here.
|
|
|
|
# The following sets edit modes for GNU EMACS
|
|
# Local Variables:
|
|
# case-fold-search:nil
|
|
# fill-prefix:" "
|
|
# adaptive-fill:nil
|
|
# fill-column:70
|
|
# End:
|