From 79af65b116a736e7f5ac5b6609664fd37805d5ec Mon Sep 17 00:00:00 2001 From: Rob Landley Date: Mon, 16 Nov 2015 03:13:22 -0600 Subject: Rewrite of the about page, re-triage of sbase, and other documentation updates. --- www/about.html | 173 ++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 115 insertions(+), 58 deletions(-) (limited to 'www/about.html') diff --git a/www/about.html b/www/about.html index 61c57a65..9e55666a 100755 --- a/www/about.html +++ b/www/about.html @@ -3,74 +3,114 @@

What is toybox?

-

Toybox combines the most common Linux command line utilities together into +

Toybox combines many common Linux command line utilities together into a single BSD-licensed executable. It's simple, small, fast, and reasonably standards-compliant (POSIX-2008 and LSB 4.1).

-

Toybox's 1.0 release goal is to turn generic Android into a -development environment capable of compiling Linux From Scratch. -A tiny system built from just toybox, linux, a C library, and a C compiler (such as LLVM or -gcc 4.2.1+binutils 2.17) should be -able to rebuild itself from source code without needing any other packages.

+

Toybox's main goal is to make Android +self-hosting +by improving Android's command line utilities so it can +build an installable Android Open Source Project image +entirely from source under a stock Android system. After a talk at the 2013 +Embedded Linux Conference explaining this plan +(outline, +video), Google +merged toybox into AOSP and +began shipping toybox in Android Mashmallow.

+ +

Toybox aims to provide one quarter of a theoretical "minimal native +development environment", which is the simplest Linux system capable of +rebuilding itself from source code and then building +Linux From Scratch +and the Android Open Source Project +under the result. In theory, this should only require four packages: +1) a set of posix-ish command line utilities, +2) a compiler[1], +3) a C library, and 4) a kernel. This provides a reproducible and auditable +base system, which with the addition of a few convienciences (vi, top, +shell command line history...) can provide a usable interactive experience +rather than just a headless build server.

-

What commands are implemented in toybox?

 +

Why is toybox?

 + +

The 2015 toybox talk +starts with links to three previous talks on the history and motivation of +the project: "Why Toybox", "Why Public Domain", and "Why did I do +Aboriginal Linux (which led me here)?". If you're really bored, +there's even a half-finished +a history page.

+ +

The toybox maintainer's earlier minimal self-hosting system project, +Aboriginal Linux, +got its minimal native development environment down to seven packages in +its 1.0 release (busybox, uClibc, gcc, binutils, make, bash, and linux) +and built Linux From Scratch under the result. That project +was the reason +toybox's maintainer became busybox maintainer, having done so +much work to extend busybox to replace all the gnu tools in a Linux From +Scratch build that the previous maintainer handed over the project (to +spend more time on buildroot).

+ +

Despite the maintainer's history with busybox, toybox is a fresh +from-scratch implementation under an +android-compatible +license. Busybox predates Android, but has never +shipped with Android due to the license. As long as we're starting over anyway, +we can do a better job.

+ +

These days, toybox is replacing busybox +in Aboriginal Linux one command at a time, and each toybox release is +regression tested by building Aboriginal Linux with it, then building +Linux From Scratch under the result with the new toybox commands. +The list of commands remaining is tracked in +the roadmap, and the replacing busybox in Aboriginal Linux is +one of the main goals for toybox' 1.0 release.

+ +

Building LFS requres fewer commands than building AOSP, which has a lot more +build +prerequisites. In theory some of those can be built from source +as external packages (we're clearly not including our own java implementation), +but some early prerequisites may need to be added to bootstrap AOSP far enough +to build them (such as a read-only version of "git": +how does repo download the AOSP source otherwise?) +[2]

+ +

What commands are planned/implemented in toybox?

The current list of commands implemented by toybox is on the status page, which is updated each release. -There is also roadmap listing all planned commands for the -1.0 release.

+There is also a roadmap listing all planned commands +for the 1.0 release and the reasons for including them.

-

In general, configuring toybox for "defconfig" enables all the commands -compete enough to be useful. Configuring "allyesconfig" enables partially +

In general, configuring toybox with "make defconfig" enables all the commands +compete enough to be useful. Configuring "allyesconfig" enables partially implemented commands as well, along with debugging features.

-

Several toybox commands can do things other vesions can't. For example -the toybox "df" isn't confused by initramfs the way other df implementations -are. (If initramfs is visible, df shows it like any other mount point.)

- -

Command Shell

 -

The toybox shell (toysh) aims to be a reasonable bash replacement. It -implements the "sh" and "toysh" commands, plus the built-in commands "cd" and -"exit". This is the largest single sub-project in toybox.

- -

The following additional commands may be built into the shell (but not as -separate executables): cd, exit, if, while, for, function, fg, bg, jobs, source, -alias, -export, set, unset, read, trap, and exec. (Note: not done yet.)

- - - -

Which commands are planned?

- -

The toybox todo list mentions many potential commands -which may be added to this project. (Whether that file is readable by anybody -but the project's maintainer is open to debate.) The roadmap wiki in the -nav bar has a more human readable version.

- -

The criteria for a toybox 1.0 release is that a system built from just the -Linux kernel, toybox, C library (such as uClibc), and a compiler (such as -tinycc) can rebuild itself from source code.

-

Relevant Standards

 -

Most commands are implemented according to +

Most commands are implemented according to POSIX-2008 (I.E. The -Single Unix Specification version 4 where applicable. This does not mean +Single Unix Specification version 4) where applicable. This does not mean that toybox is implementing every SUSv4 utility: some such as SCCS and ed are obsolete, while others such as c99 are outside the scope of the project. Toybox also isn't implementing full internationalization support: it should be 8-bit clean and handle UTF-8, but otherwise we leave this to X11 and higher layers. And some things (like $CDPATH support in "cd") await a good -explanation of why to bother with them. (The standard provides an important -frame of reference, but is not infallable set of commandments to be blindly -obeyed.)

- -

The other major sources of commands are the Linux man pages, and testing -the behavior of existing commands (although not generally looking at their +explanation of why to bother with them. (POSIX provides an important +frame of reference, but is not an infallable set of commandments to be blindly +obeyed. We do try to document our deviations from it in the comment section +at the start of each command under toys/posix.)

+ +

The other major sources of commands are the Linux man pages, the +Linux Standard Base, and testing the behavior of existing command +implementations (although not generally looking at their source code), including the commands in Android's toolbox. SUSv4 does not include many basic commands such as "mount", "init", and "mke2fs", which are kind of nice to have.

+

For more on this see the roadmap and +design goals.

+

Download

This project is maintained as a git @@ -78,29 +118,46 @@ archive, and also offers source tarballs and static binaries of the release versions.

-

The maintainer's development log and the project's +

The maintainer's development log and the project's mailing list are also good ways to track what's going on with the project.

-

Why is toybox?

 - -

The 2015 toybox talk -starts with links to three previous talks on the history and motivation of -the project: "Why Toybox", "Why Public Domain", and "Why did I do -Aboriginal Linux (which led me here)?".

-

What's the toybox logo image?

 -

It's carefully stacked soda cans. Specifically, +

It's carefully stacked soda cans. Specifically, it's a bunch of the original "Coke Zero" and "Pepsi One" cans, circa 2006, stacked to spell out the binary values of the ascii string "Toybox", with -null terminator at the bottom. (The big picture's on it's side because +null terminator at the bottom. (The big picture's on it's side because the camera was held sideways to get a better shot.)

No, it's not photoshopped, I actually had these cans until a coworker who Totally Did Not Get It tm threw them out one day after I'd gone home, -thinking they were recycling. (I still have two of each kind, but +thinking they were recycling. (I still have two of each kind, but Pepsi One seems discontinued and Coke Zero switched its can color -from black to grey, presumably in celebration. It was fun while it lasted...)

+from black to grey, presumably in celebration. It was fun while it lasted...)

+ +

Footnoes

 + +

[1] Ok, most toolchains (gcc, llvm, pcc, libfirm...) +are multiple packages, but the maintainer of toybox used to maintain a +fork of tinycc (an integrated +compiler/assembler/linker which once upon a +time did build a bootable linux +kernel before its original developer abandoned the project), +and has vague plans of trying +again someday. The compiler toolchain is _conceptually_ one package, +implementable as a single multicall binary acting like make, cc, as, ld, cpp, +strip, readelf, nm, objdump, and so on as necessary. It's just the existing +packages that do this kinda suck don't. (In theory "make" +belongs in qcc, in practice llvm hasn't got its own make so toybox probably +needs to add it after 1.0 to eliminate another gpl build prerequite from +AOSP.)

+ +

[2] +The dividing line is +"Is there an acceptably licensed version Android can ship, or do we have +to write one?" Since android is not "GNU/Linux" in any way, we need to +clean out all traces of gnu software from its build to get a clean +self-hosting system.

-- cgit v1.2.3