blob: 47fe6cdb299063cec4736e7f4ada92f9c007f8cb [file] [log] [blame]
Rob Landley4e68de12007-12-13 07:00:27 -06001<!--#include file="header.html" -->
2
3<p><h1>Infrastructure:</h1></p>
4
5<p>The toybox source code is in three directories. The top level directory
6contains the file main.c and the header file toys.h. The "lib" directory
7contains generic functions shared by multiple commands. The "toys" directory
8contains the implementations of individual commands.</p>
9
10<p><h2>Top level directory.</h2></p>
11
12<p>lib: llist, getmountlist(), error_msg/error_exit, xmalloc(),
13strlcpy(), xexec(), xopen()/xread(), xgetcwd(), xabspath(), find_in_path(),
14itoa().</p>
15
16<h3>main.c</h3>
17<p>Contains the main() function where execution starts, plus
18common infrastructure to initialize global variables and select which command
19to run.</p>
20
21<p>Execution starts in main() which removes the path from the first command
22name and calls toybox_main(), which calls toy_exec(), which calls toy_find(),
23toy_init() and the appropriate command's function from toy_list.</p>
24
25<p>The following global variables are defined here:</p>
26<ul>
27<li><p>struct toy_list <b>toy_list[]</b> - array describing all the
28commands currently configured into toybox. The first entry (toy_list[0]) is
29for the "toybox" multiplexer command, which runs all the other built-in commands
30without symlinks by using its first argument as the name of the command to
31run and the rest as that command's argument list (ala "./toybox echo hello").
32The remaining entries are the commands in alphabetical order (for efficient
33binary search).</p>
34
35<p>This is a read-only array initialized at compile time by
36defining macros and #including toys/toylist.h.</p>
37
38<p>Members of struct toy_list include:</p>
39<ul>
40<li><p>char *<b>name</b> - the name of this command.</p></li>
41<li><p>void (*<b>toy_main</b>)(void) - function pointer to run this
42command.</p></li>
43<li><p>char *<b>options</b> - command line option string (used by
44get_optflags() in lib/args.c to intialize toys.optflags, toys.optargs, and
45entries in the toy union). If this is NULL, no option parsing is done before
46calling toy_main().</p></li>
47<li><p>int <b>flags</b> - Behavior flags such as where to install this command
48(in usr/bin/sbin) and whether this is a shell builtin (NOFORK) or a standalone
49command.</p></li>
50</ul><br>
51</li>
52
53<li><p>struct toy_context <b>toys</b> - global structure containing information
54common to all commands, initializd by toy_init(). Members of this structure
55include:</p>
56<ul>
57<li><p>struct toy_list *<b>which</b> - a pointer to this command's toy_list
58structure. Mostly used to grab the name of the running command
59(toys->which.name).</p>
60</li>
61<li><p>int <b>exitval</b> - Exit value of this command. Defaults to zero. The
62error_exit() functions will return 1 if this is zero, otherwise they'll
63return this value.</p></li>
64<li><p>char **<b>argv</b> - "raw" command line options, I.E. the original
65unmodified string array passed in to main(). Note that modifying this changes
66"ps" output, and is not recommended.</p>
67<p>Most commands don't use this field, instead the use optargs, optflags,
68and the fields in the toy union initialized by get_optflags().</p>
69</li>
70<li><p>unsigned <b>optflags</b> - Command line option flags, set by
71get_optflags(). Indicates which of the command line options listed in
72toys->which.options were seen this time. See get_optflags() for
73details.</p></li>
74<li><p>char **<b>optargs</b> - Null terminated array of arguments left over
75after get_optflags() removed all the ones it understood. Note: optarg[0] is
76the first argument, not the command name. Use toys.which->name for the command
77name.</p></li>
78<li><p>int <b>exithelp</b> - Whether error_exit() should print a usage message
79via help_main() before exiting. (True during option parsing, defaults to
80false afterwards.)</p></li>
81</ul><br>
82
83<li><p>union toy_union <b>toy</b> - Union of structures containing each
84command's global variables.</p>
85
86<p>A command that needs global variables should declare a structure to
87contain them all, and add that structure to this union. A command should never
88declare global variables outside of this, because such global variables would
89allocate memory when running other commands that don't use those global
90variables.</p>
91
92<p>The first few fields of this structure can be intialized by get_optargs(),
93as specified by the options field off this command's toy_list entry. See
94the get_optargs() description in lib/args.c for details.</p>
95</li>
96
Rob Landley81b899d2007-12-18 02:02:47 -060097<li><b>char toybuf[4096]</b> - a common scratch space buffer so
Rob Landley4e68de12007-12-13 07:00:27 -060098commands don't need to allocate their own. Any command is free to use this,
99and it should never be directly referenced by functions in lib/ (although
100commands are free to pass toybuf in to a library function as an argument).</li>
101</ul>
102
103<p>The following functions are defined here:</p>
104<ul>
105<li><p>struct toy_list *<b>toy_find</b>(char *name) - Return the toy_list
106structure for this command name, or NULL if not found.</p></li>
Rob Landley81b899d2007-12-18 02:02:47 -0600107<li><p>void <b>toy_init</b>(struct toy_list *which, char *argv[]) - fill out
108the global toys structure, calling get_optargs() if necessary.</p></li>
Rob Landley4e68de12007-12-13 07:00:27 -0600109<li><p>void <b>toy_exec</b>(char *argv[]) - Run a built-in command with arguments.
110Calls toy_find() on the first argument (which must be just a command name
111without path). Returns if it can't find this command, otherwise calls
112toy_init(), toys->which.toy_main(), and exit() instead of returning.</p></li>
113
114<li><p>void <b>toybox_main</b>(void) - the main function for multiplexer
115command. Given a command name as its first argument, calls toy_exec() on its
116arguments. With no arguments, it lists available commands. If the first
117argument starts with "-" it lists each command with its default install
118path prepended.</p></li>
119
120</ul>
121
122<h3>Config.in</h3>
123
124<p>Top level configuration file in a stylized variant of
125<a href=http://kernel.org/doc/Documentation/kbuild/kconfig-language.txt>kconfig</a> format. Includes toys/Config.in.</p>
126
127<p>These files are directly used by "make menuconfig" to select which commands
128to build into toybox (thus generating a .config file), and by
129scripts/config2help.py to generate toys/help.h.</p>
130
131<h3>Temporary files:</h3>
132
133<ul>
134<li><p><b>.config</b> - Configuration file generated by kconfig, indicating
135which commands (and options to commands) are currently enabled. Used
136to generate gen_config.h and the toys/*.c dependency list.</p></li>
137
138<li><p><b>gen_config.h</b> - list of CFG_SYMBOL and USE_SYMBOL() macros,
139generated from .config by a sed invocation in the top level Makefile.</p>
140
141<p>CFG_SYMBOL is a comple time constant set to 1 for enabled symbols and 0 for
142disabled symbols. This can be used via normal if() statements to remove
143code at compile time via the optimizer's dead code elimination, which removes
144from the binary any code that cannot be reached. This saves space without
145cluttering the code with #ifdefs or leading to configuration dependent build
146breaks. (See the 1992 Usenix paper
147<a href=http://www.chris-lott.org/resources/cstyle/ifdefs.pdf>#ifdef
148Considered Harmful</a> for more information.)</p>
149
150<p>USE_SYMBOL(code) evaluates to the code in parentheses when the symbol
151is enabled, and nothing when the symbol is disabled. This can be used
152for things like varargs or variable declarations which can't always be
153eliminated by a compile time removalbe test on CFG_SYMBOL. Note that
154(unlike CFG_SYMBOL) this is really just a variant of #ifdef, and can
155still result in configuration dependent build breaks. Use with caution.</p>
156</li>
157</ul>
158
Rob Landley81b899d2007-12-18 02:02:47 -0600159<p><h2>Directory toys/</h2></p>
Rob Landley4e68de12007-12-13 07:00:27 -0600160
161<h3>toys/Config.in</h3>
162
163<p>Included from the top level Config.in, contains one or more
164configuration entries for each command.</p>
165
Rob Landley81b899d2007-12-18 02:02:47 -0600166<p>Each command has a configuration entry matching the command name (although
167configuration symbols are uppercase and command names are lower case).
Rob Landley4e68de12007-12-13 07:00:27 -0600168Options to commands start with the command name followed by an underscore and
169the option name. Global options are attachd to the "toybox" command,
170and thus use the prefix "TOYBOX_". This organization is used by
Rob Landley81b899d2007-12-18 02:02:47 -0600171scripts/cfg2files to select which toys/*.c files to compile for a given
172.config.</p>
Rob Landley4e68de12007-12-13 07:00:27 -0600173
174<p>A commands with multiple names (or multiple similar commands implemented in
175the same .c file) should have config symbols prefixed with the name of their
176C file. I.E. config symbol prefixes are NEWTOY() names. If OLDTOY() names
177have config symbols they're options (symbols with an underscore and suffix)
178to the NEWTOY() name. (See toys/toylist.h)</p>
179
180<h3>toys/toylist.h</h3>
Rob Landley81b899d2007-12-18 02:02:47 -0600181<p>The first half of this file prototypes all the structures to hold
Rob Landleyda09b7f2007-12-20 06:29:59 -0600182global variables for each command, and puts them in toy_union. These
183prototypes are only included if the macro NEWTOY isn't defined (in which
184case NEWTOY is defined to a default value that produces function
185prototypes).</p>
Rob Landley81b899d2007-12-18 02:02:47 -0600186
Rob Landleyda09b7f2007-12-20 06:29:59 -0600187<p>The second half of this file lists all the commands in alphabetical
188order, along with their command line arguments and install location.
189Each command has an appropriate configuration guard so only the commands that
190are enabled wind up in the list.</p>
191
192<p>The first time this header is #included, it defines structures and
193produces function prototypes for the commands in the toys directory.</p>
194
195
196<p>The first time it's included, it defines structures and produces function
197prototypes.
198 This
Rob Landley81b899d2007-12-18 02:02:47 -0600199is used to initialize toy_list in main.c, and later in that file to initialize
200NEED_OPTIONS (to figure out whether the command like parsing logic is needed),
201and to put the help entries in the right order in toys/help.c.</p>
Rob Landley4e68de12007-12-13 07:00:27 -0600202
203<h3>toys/help.h</h3>
204
205<p>#defines two help text strings for each command: a single line
206command_help and an additinal command_help_long. This is used by help_main()
207in toys/help.c to display help for commands.</p>
208
209<p>Although this file is generated from Config.in help entries by
210scripts/config2help.py, it's shipped in release tarballs so you don't need
211python on the build system. (If you check code out of source control, or
212modify Config.in, then you'll need python installed to rebuild it.)</p>
213
214<p>This file contains help for all commands, regardless of current
215configuration, but only the currently enabled ones are entered into help_data[]
216in toys/help.c.</p>
217
Rob Landley81b899d2007-12-18 02:02:47 -0600218<h2>Directory lib/</h2>
Rob Landley4e68de12007-12-13 07:00:27 -0600219
Rob Landley81b899d2007-12-18 02:02:47 -0600220<h2>Directory scripts/</h2>
Rob Landley4e68de12007-12-13 07:00:27 -0600221
222<h3>scripts/cfg2files.sh</h3>
223
224<p>Run .config through this filter to get a list of enabled commands, which
225is turned into a list of files in toys via a sed invocation in the top level
226Makefile.
227</p>
228
Rob Landley81b899d2007-12-18 02:02:47 -0600229<h2>Directory kconfig/</h2>
Rob Landley4e68de12007-12-13 07:00:27 -0600230
231<p>Menuconfig infrastructure copied from the Linux kernel. See the
232Linux kernel's Documentation/kbuild/kconfig-language.txt</p>
233
234<!--#include file="footer.html" -->