1 <html><head><title>What is toybox?</title> 2 <!--#include file="header.html" --> 3 4 <h2><a name="what" />What is toybox?</h2> 5 6 <p>Toybox combines many common Linux command line utilities together into 7 a single <a href=license.html>BSD-licensed</a> executable. It's simple, small, fast, and reasonably 8 standards-compliant (<a href=http://opengroup.org/onlinepubs/9699919799>POSIX-2008</a> and <a href=http://refspecs.linuxfoundation.org/LSB_4.1.0>LSB 4.1</a>).</p> 9 10 <p>Toybox's main goal is to make Android 11 <a href=http://landley.net/aboriginal/about.html#selfhost>self-hosting</a> 12 by improving Android's command line utilities so it can 13 build an installable Android Open Source Project image 14 entirely from source under a stock Android system. After a talk at the 2013 15 Embedded Linux Conference explaining this plan 16 (<a href=http://landley.net/talks/celf-2013.txt>outline</a>, 17 <a href=https://www.youtube.com/watch?v=SGmtP5Lg_t0>video</a>), Google 18 <a href=https://lwn.net/Articles/629362/>merged toybox into AOSP</a> and 19 began shipping toybox in Android Mashmallow.</p> 20 21 <p>Toybox aims to provide one quarter of a theoretical "minimal native 22 development environment", which is the simplest Linux system capable of 23 rebuilding itself from source code and then building 24 <a href=http://linuxfromscratch.org/lfs>Linux From Scratch</a> 25 and the <a href=https://source.android.com>Android Open Source Project</a> 26 under the result. In theory, this should only require four packages: 27 1) a set of posix-ish command line utilities, 28 2) a compiler<a name="1_back"></a><sup><font size=-3><a href=#1>[1]</a></font></sup>, 29 3) a C library, and 4) a kernel. This provides a reproducible and auditable 30 base system, which with the addition of a few convienciences (vi, top, 31 shell command line history...) can provide a usable interactive experience 32 rather than just a headless build server.</p> 33 34 <b><h2><a name="why" />Why is toybox?</h2></b> 35 36 <p>The <a href=http://landley.net/talks/celf-2013.txt>2013 toybox talk</a> 37 at ELC was devoted to this question, and has the following sections:</p> 38 39 <ul> 40 <li>0m29s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=0m29s>The smartphone is replacing the PC</a></li> 41 <ul> 42 <li>4m22s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=4m22s>Software needed to become self-hosting</a></li> 43 <li>6m20s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=6m20s>Do we care if android or iphone wins?</a></li> 44 </ul> 45 <li>9m45s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=9m45s>Android not vanilla: oppose or accept?</a></li> 46 <ul> 47 <li>11m30s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=11m30s>Open source can't do User Interfaces</a></li> 48 </ul> 49 <li>15m09s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=15m09s>Android is not copyleft: oppose or accept?</a></li> 50 <li>18m23s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=18m23s>Security issues</a></li> 51 <li>21m15s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=21m15s>Solutions to the software problems</a></li> 52 <ul> 53 <li>22m55s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=22m55s>What toybox needs to be/do</a></li> 54 <li>28m17s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=28m17s>What is toybox?</a></li> 55 <ul> 56 <li>28m58s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=28m58s>Why toybox started...</a></li> 57 <li>37m50s <a href=http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=37m50s>What does toybox actually implement?</a></li> 58 </ul> 59 </ul> 60 </ul> 61 62 <p>The <a href=http://landley.net/talks/celf-2015.txt>2015 toybox talk</a> 63 starts with links to three previous talks on the history and motivation of 64 the project: "Why Toybox", "Why Public Domain", and "Why did I do 65 Aboriginal Linux (which led me here)?". If you're really bored, 66 there's even a half-finished 67 <a href=http://landley.net/aboriginal/history.html>a history page</a>.</p> 68 69 <p>The toybox maintainer's earlier minimal self-hosting system project, 70 <a href=http://landley.net/aboriginal/about.html>Aboriginal Linux</a>, 71 got its minimal native development environment down to seven packages in 72 its 1.0 release (busybox, uClibc, gcc, binutils, make, bash, and linux) 73 and built Linux From Scratch under the result. That project 74 <a href=http://landley.net/aboriginal/history.html>was the reason</a> 75 toybox's maintainer became busybox maintainer, having done so 76 much work to extend busybox to replace all the gnu tools in a Linux From 77 Scratch build that the previous maintainer handed over the project (to 78 spend more time on buildroot).</p> 79 80 <p>Despite the maintainer's history with busybox, toybox is a fresh 81 from-scratch implementation under an 82 <a href=https://source.android.com/source/licenses.html>android-compatible</a> 83 <a href=license.html>license</a>. Busybox predates Android, but has never 84 shipped with Android due to the license. As long as we're starting over anyway, 85 we can do a better job.</p> 86 87 <p>These days, toybox is replacing busybox 88 in Aboriginal Linux one command at a time, and each toybox release is 89 regression tested by building Aboriginal Linux with it, then building 90 Linux From Scratch under the result with the new toybox commands. 91 The list of commands remaining is tracked <a href=roadmap.html#dev_env>in 92 the roadmap</a>, and the replacing busybox in Aboriginal Linux is 93 one of the main goals for toybox' 1.0 release.</p> 94 95 <p>Building LFS requres fewer commands than building AOSP, which has a lot more 96 <a href=http://source.android.com/source/initializing.html>build 97 prerequisites</a>. In theory some of those can be built from source 98 as external packages (we're clearly not including our own java implementation), 99 but some early prerequisites may need to be added to bootstrap AOSP far enough 100 to build them (such as a read-only version of "git": 101 how does repo download the AOSP source otherwise?) 102 <a name="2_back"></a><sup><font size=-3><a href=#2>[2]</a></font></sup></p> 103 104 <b><h2><a name="status" />What commands are planned/implemented in toybox?</h2></b> 105 106 <p>The current list of commands implemented by toybox is on the 107 <a href=status.html>status page</a>, which is updated each release. 108 There is also a <a href=roadmap.html>roadmap</a> listing all planned commands 109 for the 1.0 release and the reasons for including them.</p> 110 111 <p>In general, configuring toybox with "make defconfig" enables all the commands 112 compete enough to be useful. Configuring "allyesconfig" enables partially 113 implemented commands as well, along with debugging features.</p> 114 115 <b><h3>Relevant Standards</h3></b> 116 117 <p>Most commands are implemented according to POSIX-2008 (I.E. 118 <a href=http://opengroup.org/onlinepubs/9699919799/idx/utilities.html>The 119 Single Unix Specification version 4</a>) where applicable. This does not mean 120 that toybox is implementing every SUSv4 utility: some such as SCCS and ed are 121 obsolete, while others such as c99 are outside the scope of the project. 122 Toybox also isn't implementing full internationalization support: it should be 123 8-bit clean and handle UTF-8, but otherwise we leave this to X11 and higher 124 layers. And some things (like $CDPATH support in "cd") await a good 125 explanation of why to bother with them. (POSIX provides an important 126 frame of reference, but is not an infallable set of commandments to be blindly 127 obeyed. We do try to document our deviations from it in the comment section 128 at the start of each command under toys/posix.)</p> 129 130 <p>The other major sources of commands are the Linux man pages, the 131 Linux Standard Base, and testing the behavior of existing command 132 implementations (although not generally looking at their 133 source code), including the commands in Android's toolbox. SUSv4 does not 134 include many basic commands such as "mount", "init", and "mke2fs", which are 135 kind of nice to have.</p> 136 137 <p>For more on this see the <a href=roadmap.html>roadmap</a> and 138 <a href=design.html>design goals</a>.</p> 139 140 <b><h2><a name="downloads" />Download</h2></b> 141 142 <p>This project is maintained as a <a href=https://github.com/landley/toybox>git 143 archive</a>, and also offers <a href=http://landley.net/toybox/downloads>source 144 tarballs</a> and <a href=http://landley.net/toybox/bin>static binaries</a> 145 of the release versions.</p> 146 147 <p>The maintainer's <a href=http://landley.net/notes.html>development log</a> and the project's 148 <a href=http://lists.landley.net/listinfo.cgi/toybox-landley.net>mailing 149 list</a> are also good ways to track what's going on with the project.</p> 150 151 <b><h2><a name="toycans" />What's the toybox logo image?</h2></b> 152 153 <p>It's <a href=toycans-big.jpg>carefully stacked soda cans</a>. Specifically, 154 it's a bunch of the original "Coke Zero" and "Pepsi One" cans, circa 2006, 155 stacked to spell out the binary values of the ascii string "Toybox", with 156 null terminator at the bottom. (The big picture's on it's side because 157 the camera was held sideways to get a better shot.)</p> 158 159 <p>No, it's not photoshopped, I actually had these cans until a coworker 160 who Totally Did Not Get It <sup><font size=-3><a href=http://www.timesys.com>tm</a></font></sup> threw them out one day after I'd gone home, 161 thinking they were recycling. (I still have two of each kind, but 162 Pepsi One seems discontinued and Coke Zero switched its can color 163 from black to grey, presumably in celebration. It was fun while it lasted...)</p> 164 165 <b><h2>Footnotes</h2></b> 166 167 <p><a name="1" /><a href="#1_back">[1]</a> Ok, most toolchains (gcc, llvm, pcc, libfirm...) 168 are multiple packages, but the maintainer of toybox used to maintain a 169 <a href=http://landley.net/tinycc>fork of tinycc</a> (an integrated 170 compiler/assembler/linker which once upon a 171 time did <a href=http://bellard.org/tcc/tccboot.html>build a bootable linux 172 kernel</a> before its original developer abandoned the project), 173 and has <a href=http://landley.net/hg/qcc/file/tip/todo/todo.txt>vague plans</a> of <a href=http://landley.net/qcc>trying 174 again someday</a>. The compiler toolchain is _conceptually_ one package, 175 implementable as a single multicall binary acting like make, cc, as, ld, cpp, 176 strip, readelf, nm, objdump, and so on as necessary. It's just the existing 177 packages that do this <strike>kinda suck</strike> don't. (In theory "make" 178 belongs in qcc, in practice llvm hasn't got its own make so toybox probably 179 needs to add it after 1.0 to eliminate another gpl build prerequite from 180 AOSP.)</p> 181 182 <p><a name="2" /><a href="#2_back">[2]</a> 183 The dividing line is 184 "Is there an acceptably licensed version Android can ship, or do we have 185 to write one?" Since android is not "GNU/Linux" in any way, we need to 186 clean out all traces of gnu software from its build to get a clean 187 self-hosting system.</p> 188 189 <!--#include file="footer.html" --> 190
