From 4e68de1ef854fadd74fcb63c3a5ad15dce457a4c Mon Sep 17 00:00:00 2001 From: Rob Landley Date: Thu, 13 Dec 2007 07:00:27 -0600 Subject: Update web pages. --- www/code.html | 213 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ www/design.html | 8 +-- www/footer.html | 2 +- www/header.html | 2 + www/index.html | 63 +++++++++-------- 5 files changed, 251 insertions(+), 37 deletions(-) create mode 100755 www/code.html (limited to 'www') diff --git a/www/code.html b/www/code.html new file mode 100755 index 00000000..12dd6785 --- /dev/null +++ b/www/code.html @@ -0,0 +1,213 @@ + + +

Infrastructure:

+ +

The toybox source code is in three directories. The top level directory +contains the file main.c and the header file toys.h. The "lib" directory +contains generic functions shared by multiple commands. The "toys" directory +contains the implementations of individual commands.

+ +

Top level directory.

+ +

lib: llist, getmountlist(), error_msg/error_exit, xmalloc(), +strlcpy(), xexec(), xopen()/xread(), xgetcwd(), xabspath(), find_in_path(), +itoa().

+ +

main.c

+

Contains the main() function where execution starts, plus +common infrastructure to initialize global variables and select which command +to run.

+ +

Execution starts in main() which removes the path from the first command +name and calls toybox_main(), which calls toy_exec(), which calls toy_find(), +toy_init() and the appropriate command's function from toy_list.

+ +

The following global variables are defined here:

+ + +

The following functions are defined here:

+ + +

Config.in

+ +

Top level configuration file in a stylized variant of +kconfig format. Includes toys/Config.in.

+ +

These files are directly used by "make menuconfig" to select which commands +to build into toybox (thus generating a .config file), and by +scripts/config2help.py to generate toys/help.h.

+ +

Temporary files:

+ + + +

toys/ directory.

+ +

toys/Config.in

+ +

Included from the top level Config.in, contains one or more +configuration entries for each command.

+ +

Each command has a configuration entry matching the command name (except +that configuration symbols are uppercase and command names are lower case). +Options to commands start with the command name followed by an underscore and +the option name. Global options are attachd to the "toybox" command, +and thus use the prefix "TOYBOX_". This organization is used by +scripts/cfg2files to select which

+ +

A commands with multiple names (or multiple similar commands implemented in +the same .c file) should have config symbols prefixed with the name of their +C file. I.E. config symbol prefixes are NEWTOY() names. If OLDTOY() names +have config symbols they're options (symbols with an underscore and suffix) +to the NEWTOY() name. (See toys/toylist.h)

+ +

toys/toylist.h

+

+ +

toys/help.h

+ +

#defines two help text strings for each command: a single line +command_help and an additinal command_help_long. This is used by help_main() +in toys/help.c to display help for commands.

+ +

Although this file is generated from Config.in help entries by +scripts/config2help.py, it's shipped in release tarballs so you don't need +python on the build system. (If you check code out of source control, or +modify Config.in, then you'll need python installed to rebuild it.)

+ +

This file contains help for all commands, regardless of current +configuration, but only the currently enabled ones are entered into help_data[] +in toys/help.c.

+ +

lib/ directory.

+ +

scripts/ directory.

+ +

scripts/cfg2files.sh

+ +

Run .config through this filter to get a list of enabled commands, which +is turned into a list of files in toys via a sed invocation in the top level +Makefile. +

+ +

kconfig/ directory.

+ +

Menuconfig infrastructure copied from the Linux kernel. See the +Linux kernel's Documentation/kbuild/kconfig-language.txt

+ + diff --git a/www/design.html b/www/design.html index 27e8af43..0c3815d4 100644 --- a/www/design.html +++ b/www/design.html @@ -181,9 +181,9 @@ don't understand the problem until you _have_ solved it.)

that works and has been paid for is a corporate asset not lightly abandoned. Open source software can afford to re-implement code that works, over and over from scratch, for incremental gains. Before toybox, the unix command line -has already been reimplemented from scratch several in a row (the -original Unix and BSD tools, the GNU tools, BusyBox...) -but maybe toybox can do a better job. :)

+has already been reimplemented from scratch several times in a row (the +original AT&T Unix command line in assembly and then in C, the BSD +versions, the GNU tools, BusyBox...) but maybe toybox can do a better job. :)

P.S. How could I resist linking to an article about why @@ -194,7 +194,7 @@ programmers should strive to be lazy and dumb?

Platforms

Toybox should run on every hardware platform Linux runs on. Other posix/susv3 environments (perhaps MacOS X or newlib+libgloss) are vaguely -interesting but only if they're easy to support, I'm not going to spend much +interesting but only if they're easy to support; I'm not going to spend much effort on them.

I don't do windows.

diff --git a/www/footer.html b/www/footer.html index 546f63b8..5647c9f4 100644 --- a/www/footer.html +++ b/www/footer.html @@ -1,7 +1,7 @@
- +
Copyright 2006 Rob Landley <rob@landley.net>
Copyright 2007 Rob Landley <rob@landley.net>
diff --git a/www/header.html b/www/header.html index eeda4aa5..6b714b24 100644 --- a/www/header.html +++ b/www/header.html @@ -16,6 +16,8 @@
  • News
  • What is it?
  • Design Docs
    • +
  • Source walkthrough
    • +
  • TODO list
    • Download