diff options
| author | Rob Landley <rob@landley.net> | 2006-05-19 20:47:55 +0000 |
|---|---|---|
| committer | Rob Landley <rob@landley.net> | 2006-05-19 20:47:55 +0000 |
| commit | df4cdaf341daa24f517d008b1f7f67271edb88a8 (patch) | |
| tree | efe2dc4352f1fc9a60e050a2da71648a182ed68d /TODO | |
| parent | 80b8ff07ca4c39114875c7fd3230c4e9ae823f83 (diff) | |
| download | busybox-w32-df4cdaf341daa24f517d008b1f7f67271edb88a8.tar.gz busybox-w32-df4cdaf341daa24f517d008b1f7f67271edb88a8.tar.bz2 busybox-w32-df4cdaf341daa24f517d008b1f7f67271edb88a8.zip | |
First quick stab at organizing TODO under whose TODO item it is.
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 199 |
1 files changed, 100 insertions, 99 deletions
| @@ -1,28 +1,111 @@ | |||
| 1 | Busybox TODO | 1 | Busybox TODO |
| 2 | 2 | ||
| 3 | Stuff that needs to be done. All of this is fair game for 1.2. | 3 | Stuff that needs to be done. This is organized by who plans to get around to |
| 4 | doing it eventually, but that doesn't mean they "own" the item. If you want to | ||
| 5 | do one of these bounce an email off the person it's listed under to see if they | ||
| 6 | have any suggestions how they plan to go about it, and to minimize conflicts | ||
| 7 | between your work and theirs. But otherwise, all of these are fair game. | ||
| 8 | |||
| 9 | Rob Landley <rob@landley.net>: | ||
| 10 | Migrate calloc() and bb_calloc() occurrences to bb_xzalloc(). | ||
| 11 | Remove obsolete _() wrapper crud for internationalization we don't do. | ||
| 12 | Figure out where we need utf8 support, and add it. | ||
| 13 | |||
| 14 | sh | ||
| 15 | The command shell situation is a big mess. We have three or four different | ||
| 16 | shells that don't really share any code, and the "standalone shell" doesn't | ||
| 17 | work all that well (especially not in a chroot environment), due to apps not | ||
| 18 | being reentrant. I'm writing a new shell (bbsh) to unify the various | ||
| 19 | shells and configurably add the minimal set of bash features people | ||
| 20 | actually use. The hardest part is it has to configure down as small as | ||
| 21 | lash while providing lash's features. The rest is easy in comparison. | ||
| 22 | bzip2 | ||
| 23 | Compression-side support. | ||
| 24 | init | ||
| 25 | General cleanup. | ||
| 26 | Unify base64 handling. | ||
| 27 | There's base64 encoding and decoding going on in: | ||
| 28 | networking/wget.c:base64enc() | ||
| 29 | coreutils/uudecode.c:read_base64() | ||
| 30 | coreutils/uuencode.c:tbl_base64[] | ||
| 31 | networking/httpd.c:decodeBase64() | ||
| 32 | And probably elsewhere. That needs to be unified into libbb functions. | ||
| 33 | Do a SUSv3 audit | ||
| 34 | Look at the full Single Unix Specification version 3 (available online at | ||
| 35 | "http://www.opengroup.org/onlinepubs/009695399/nfindex.html") and | ||
| 36 | figure out which of our apps are compliant, and what we're missing that | ||
| 37 | we might actually care about. | ||
| 38 | |||
| 39 | Even better would be some kind of automated compliance test harness that | ||
| 40 | exercises each command line option and the various corner cases. | ||
| 41 | Internationalization | ||
| 42 | How much internationalization should we do? | ||
| 43 | |||
| 44 | The low hanging fruit is UTF-8 character set support. We should do this. | ||
| 45 | (Vodz pointed out the shell's cmdedit as needing work here. What else?) | ||
| 46 | |||
| 47 | We also have lots of hardwired english text messages. Consolidating this | ||
| 48 | into some kind of message table not only makes translation easier, but | ||
| 49 | also allows us to consolidate redundant (or close) strings. | ||
| 50 | |||
| 51 | We probably don't want to be bloated with locale support. (Not unless we | ||
| 52 | can cleanly export it from our underlying C library without having to | ||
| 53 | concern ourselves with it directly. Perhaps a few specific things like a | ||
| 54 | config option for "date" are low hanging fruit here?) | ||
| 55 | |||
| 56 | What level should things happen at? How much do we care about | ||
| 57 | internationalizing the text console when X11 and xterms are so much better | ||
| 58 | at it? (There's some infrastructure here we don't implement: The | ||
| 59 | "unicode_start" and "unicode_stop" shell scripts need "vt-is-UTF8" and a | ||
| 60 | --unicode option to loadkeys. That implies a real loadkeys/dumpkeys | ||
| 61 | implementation to replace loadkmap/dumpkmap. Plus messing with console font | ||
| 62 | loading. Is it worth it, or do we just say "use X"?) | ||
| 63 | |||
| 64 | Individual compilation of applets. | ||
| 65 | It would be nice if busybox had the option to compile to individual applets, | ||
| 66 | for people who want an alternate implementation less bloated than the gnu | ||
| 67 | utils (or simply with less political baggage), but without it being one big | ||
| 68 | executable. | ||
| 69 | |||
| 70 | Turning libbb into a real dll is another possibility, especially if libbb | ||
| 71 | could export some of the other library interfaces we've already more or less | ||
| 72 | got the code for (like zlib). | ||
| 73 | buildroot - Make a "dogfood" option | ||
| 74 | Busybox 1.1 will be capable of replacing most gnu packages for real world | ||
| 75 | use, such as developing software or in a live CD. It needs wider testing. | ||
| 76 | |||
| 77 | Busybox should now be able to replace bzip2, coreutils, e2fsprogs, file, | ||
| 78 | findutils, gawk, grep, inetutils, less, modutils, net-tools, patch, procps, | ||
| 79 | sed, shadow, sysklogd, sysvinit, tar, util-linux, and vim. The resulting | ||
| 80 | system should be self-hosting (I.E. able to rebuild itself from source | ||
| 81 | code). This means it would need (at least) binutils, gcc, and make, or | ||
| 82 | equivalents. | ||
| 83 | |||
| 84 | It would be a good "eating our own dogfood" test if buildroot had the option | ||
| 85 | of using a "make allyesconfig" busybox instead of the all of the above | ||
| 86 | packages. Anything that's wrong with the resulting system, we can fix. (It | ||
| 87 | would be nice to be able to upgrade busybox to be able to replace bash and | ||
| 88 | diffutils as well, but we're not there yet.) | ||
| 89 | |||
| 90 | One example of an existing system that does this already is Firmware Linux: | ||
| 91 | http://www.landley.net/code/firmware | ||
| 92 | initramfs | ||
| 93 | Busybox should have a sample initramfs build script. This depends on | ||
| 94 | bbsh, mdev, and switch_root. | ||
| 95 | |||
| 96 | |||
| 97 | Bernhard Fischer <rep.nop@anon.at>: | ||
| 98 | Makefile stuff: | ||
| 99 | make -j is broken, -j1 is forced atm | ||
| 100 | |||
| 101 | As yet unclaimed: | ||
| 4 | 102 | ||
| 5 | build system | ||
| 6 | make -j is broken, -j1 is forced atm | ||
| 7 | Make sure that the flags get pinned in e.g. Rules.mak so when expanding them | ||
| 8 | later on you get the cached result without the need to re-evaluate them. | ||
| 9 | ---- | 103 | ---- |
| 10 | find | 104 | find |
| 11 | doesn't understand (), lots of susv3 stuff. | 105 | doesn't understand (), lots of susv3 stuff. |
| 12 | ---- | 106 | ---- |
| 13 | sh | ||
| 14 | The command shell situation is a big mess. We have three or four different | ||
| 15 | shells that don't really share any code, and the "standalone shell" doesn't | ||
| 16 | work all that well (especially not in a chroot environment), due to apps not | ||
| 17 | being reentrant. Unifying the various shells and figuring out a configurable | ||
| 18 | way of adding the minimal set of bash features a given script uses is a big | ||
| 19 | job, but it would be a big improvement. | ||
| 20 | |||
| 21 | Note: Rob Landley (rob@landley.net) is working on a new unified shell called | ||
| 22 | bbsh, but it's a low priority... | ||
| 23 | --- | ||
| 24 | diff | 107 | diff |
| 25 | Also, make sure we handle empty files properly: | 108 | Make sure we handle empty files properly: |
| 26 | From the patch man page: | 109 | From the patch man page: |
| 27 | 110 | ||
| 28 | you can remove a file by sending out a context diff that compares | 111 | you can remove a file by sending out a context diff that compares |
| @@ -45,18 +128,9 @@ man | |||
| 45 | 128 | ||
| 46 | (How doclifter might work into this is anybody's guess.) | 129 | (How doclifter might work into this is anybody's guess.) |
| 47 | --- | 130 | --- |
| 48 | bzip2 | ||
| 49 | Compression-side support. | ||
| 50 | --- | ||
| 51 | init | ||
| 52 | General cleanup. | ||
| 53 | --- | ||
| 54 | ar | 131 | ar |
| 55 | Write support? | 132 | Write support? |
| 56 | --- | 133 | --- |
| 57 | mdev | ||
| 58 | Micro-udev. | ||
| 59 | --- | ||
| 60 | crond | 134 | crond |
| 61 | turn FEATURE_DEBUG_OPT into ENABLE_FEATURE_CROND_DEBUG_OPT | 135 | turn FEATURE_DEBUG_OPT into ENABLE_FEATURE_CROND_DEBUG_OPT |
| 62 | 136 | ||
| @@ -74,46 +148,6 @@ bb_close() with fsync() | |||
| 74 | You need to call fsync() if you care about errors that occur after write(), | 148 | You need to call fsync() if you care about errors that occur after write(), |
| 75 | but that can have a big performance impact. So make it a config option. | 149 | but that can have a big performance impact. So make it a config option. |
| 76 | --- | 150 | --- |
| 77 | Unify base64 handling. | ||
| 78 | There's base64 encoding and decoding going on in: | ||
| 79 | networking/wget.c:base64enc() | ||
| 80 | coreutils/uudecode.c:read_base64() | ||
| 81 | coreutils/uuencode.c:tbl_base64[] | ||
| 82 | networking/httpd.c:decodeBase64() | ||
| 83 | And probably elsewhere. That needs to be unified into libbb functions. | ||
| 84 | --- | ||
| 85 | Do a SUSv3 audit | ||
| 86 | Look at the full Single Unix Specification version 3 (available online at | ||
| 87 | "http://www.opengroup.org/onlinepubs/009695399/nfindex.html") and | ||
| 88 | figure out which of our apps are compliant, and what we're missing that | ||
| 89 | we might actually care about. | ||
| 90 | |||
| 91 | Even better would be some kind of automated compliance test harness that | ||
| 92 | exercises each command line option and the various corner cases. | ||
| 93 | --- | ||
| 94 | Internationalization | ||
| 95 | How much internationalization should we do? | ||
| 96 | |||
| 97 | The low hanging fruit is UTF-8 character set support. We should do this. | ||
| 98 | (Vodz pointed out the shell's cmdedit as needing work here. What else?) | ||
| 99 | |||
| 100 | We also have lots of hardwired english text messages. Consolidating this | ||
| 101 | into some kind of message table not only makes translation easier, but | ||
| 102 | also allows us to consolidate redundant (or close) strings. | ||
| 103 | |||
| 104 | We probably don't want to be bloated with locale support. (Not unless we can | ||
| 105 | cleanly export it from our underlying C library without having to concern | ||
| 106 | ourselves with it directly. Perhaps a few specific things like a config | ||
| 107 | option for "date" are low hanging fruit here?) | ||
| 108 | |||
| 109 | What level should things happen at? How much do we care about | ||
| 110 | internationalizing the text console when X11 and xterms are so much better | ||
| 111 | at it? (There's some infrastructure here we don't implement: The | ||
| 112 | "unicode_start" and "unicode_stop" shell scripts need "vt-is-UTF8" and a | ||
| 113 | --unicode option to loadkeys. That implies a real loadkeys/dumpkeys | ||
| 114 | implementation to replace loadkmap/dumpkmap. Plus messing with console font | ||
| 115 | loading. Is it worth it, or do we just say "use X"?) | ||
| 116 | --- | ||
| 117 | Unify archivers | 151 | Unify archivers |
| 118 | Lots of archivers have the same general infrastructure. The directory | 152 | Lots of archivers have the same general infrastructure. The directory |
| 119 | traversal code should be factored out, and the guts of each archiver could | 153 | traversal code should be factored out, and the guts of each archiver could |
| @@ -129,39 +163,6 @@ Text buffer support. | |||
| 129 | a whole file into memory and act on it. There might be an opportunity | 163 | a whole file into memory and act on it. There might be an opportunity |
| 130 | for shared code in there that could be moved into libbb... | 164 | for shared code in there that could be moved into libbb... |
| 131 | --- | 165 | --- |
| 132 | Individual compilation of applets. | ||
| 133 | It would be nice if busybox had the option to compile to individual applets, | ||
| 134 | for people who want an alternate implementation less bloated than the gnu | ||
| 135 | utils (or simply with less political baggage), but without it being one big | ||
| 136 | executable. | ||
| 137 | |||
| 138 | Turning libbb into a real dll is another possibility, especially if libbb | ||
| 139 | could export some of the other library interfaces we've already more or less | ||
| 140 | got the code for (like zlib). | ||
| 141 | --- | ||
| 142 | buildroot - Make a "dogfood" option | ||
| 143 | Busybox 1.1 will be capable of replacing most gnu packages for real world use, | ||
| 144 | such as developing software or in a live CD. It needs wider testing. | ||
| 145 | |||
| 146 | Busybox should now be able to replace bzip2, coreutils, e2fsprogs, file, | ||
| 147 | findutils, gawk, grep, inetutils, less, modutils, net-tools, patch, procps, | ||
| 148 | sed, shadow, sysklogd, sysvinit, tar, util-linux, and vim. The resulting | ||
| 149 | system should be self-hosting (I.E. able to rebuild itself from source code). | ||
| 150 | This means it would need (at least) binutils, gcc, and make, or equivalents. | ||
| 151 | |||
| 152 | It would be a good "eating our own dogfood" test if buildroot had the option | ||
| 153 | of using a "make allyesconfig" busybox instead of the all of the above | ||
| 154 | packages. Anything that's wrong with the resulting system, we can fix. (It | ||
| 155 | would be nice to be able to upgrade busybox to be able to replace bash and | ||
| 156 | diffutils as well, but we're not there yet.) | ||
| 157 | |||
| 158 | One example of an existing system that does this already is Firmware Linux: | ||
| 159 | http://www.landley.net/code/firmware | ||
| 160 | --- | ||
| 161 | initramfs | ||
| 162 | Busybox should have a sample initramfs build script. This depends on | ||
| 163 | bbsh, mdev, and switch_root. | ||
| 164 | --- | ||
| 165 | Memory Allocation | 166 | Memory Allocation |
| 166 | We have a CONFIG_BUFFER mechanism that lets us select whether to do memory | 167 | We have a CONFIG_BUFFER mechanism that lets us select whether to do memory |
| 167 | allocation on the stack or the heap. Unfortunately, we're not using it much. | 168 | allocation on the stack or the heap. Unfortunately, we're not using it much. |