tweak TODO file
authorDenys Vlasenko <vda.linux@googlemail.com>
Sat, 19 Jun 2010 20:15:20 +0000 (22:15 +0200)
committerDenys Vlasenko <vda.linux@googlemail.com>
Sat, 19 Jun 2010 20:15:20 +0000 (22:15 +0200)
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
TODO

diff --git a/TODO b/TODO
index af4c467c2d332e6f0a40eaf0290b9893e9e140f5..6f8cd8a3262bb09c75e934f64e67aacb87e71192 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,5 +1,8 @@
 Busybox TODO
 
+Harvest patches from
+http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/busybox/
+
 Stuff that needs to be done.  This is organized by who plans to get around to
 doing it eventually, but that doesn't mean they "own" the item.  If you want to
 do one of these bounce an email off the person it's listed under to see if they
@@ -9,9 +12,6 @@ between your work and theirs.  But otherwise, all of these are fair game.
 Rob Landley suggested this:
   Implement bb_realpath() that can handle NULL on non-glibc.
 
-  Remove obsolete _() wrapper crud for internationalization we don't do.
-  Figure out where we need utf8 support, and add it.
-
   sh
     The command shell situation is a mess.  We have two different
     shells that don't really share any code, and the "standalone shell" doesn't
@@ -31,7 +31,7 @@ Rob Landley suggested this:
     How much internationalization should we do?
 
     The low hanging fruit is UTF-8 character set support.  We should do this.
-    (Vodz pointed out the shell's cmdedit as needing work here.  What else?)
+    See TODO_unicode file.
 
     We also have lots of hardwired english text messages.  Consolidating this
     into some kind of message table not only makes translation easier, but
@@ -59,6 +59,7 @@ Rob Landley suggested this:
     Turning libbb into a real dll is another possibility, especially if libbb
     could export some of the other library interfaces we've already more or less
     got the code for (like zlib).
+
   buildroot - Make a "dogfood" option
     Busybox 1.1 will be capable of replacing most gnu packages for real world
     use, such as developing software or in a live CD.  It needs wider testing.
@@ -78,22 +79,25 @@ Rob Landley suggested this:
 
     One example of an existing system that does this already is Firmware Linux:
       http://www.landley.net/code/firmware
+
   initramfs
     Busybox should have a sample initramfs build script.  This depends on
     bbsh, mdev, and switch_root.
+
   mkdep
     Write a mkdep that doesn't segfault if there's a directory it doesn't
     have permission to read, isn't based on manually editing the output of
     lexx and yacc, doesn't make such a mess under include/config, etc.
+
   Group globals into unions of structures.
     Go through and turn all the global and static variables into structures,
     and have all those structures be in a big union shared between processes,
     so busybox uses less bss.  (This is a big win on nommu machines.)  See
     sed.c and mdev.c for examples.
+
   Go through bugs.busybox.net and close out all of that somehow.
     This one's open to everybody, but I'll wind up doing it...
 
-
 Bernhard Reutner-Fischer <busybox@busybox.net> suggests to look at these:
   New debug options:
     -Wlarger-than-127
@@ -177,40 +181,6 @@ Memory Allocation
   call free might also be optimized out by the compiler if written right, so
   we can yank those #ifdefs too, and generally clean up the code.
 ---
-Switch CONFIG_SYMBOLS to ENABLE_SYMBOLS
-
-  In busybox 1.0 and earlier, configuration was done by CONFIG_SYMBOLS
-  that were either defined or undefined to indicate whether the symbol was
-  selected in the .config file.  They were used with #ifdefs, ala:
-
-    #ifdef CONFIG_SYMBOL
-      if (other_test) {
-        do_code();
-      }
-    #endif
-
-  In 1.1, we have new ENABLE_SYMBOLS which are always defined (as 0 or 1),
-  meaning you can still use them for preprocessor tests by replacing
-  "#ifdef CONFIG_SYMBOL" with "#if ENABLE_SYMBOL".  But more importantly, we
-  can use them as a true or false test in normal C code:
-
-    if (ENABLE_SYMBOL && other_test) {
-      do_code();
-    }
-
-  (Optimizing away if() statements that resolve to a constant value
-  is known as "dead code elimination", an optimization so old and simple that
-  Turbo Pascal for DOS did it twenty years ago.  Even modern mini-compilers
-  like the Tiny C Compiler (tcc) and the Small Device C Compiler (SDCC)
-  perform dead code elimination.)
-
-  Right now, busybox.h is #including both "config.h" (defining the
-  CONFIG_SYMBOLS) and "bb_config.h" (defining the ENABLE_SYMBOLS).  At some
-  point in the future, it would be nice to wean ourselves off of the
-  CONFIG versions.  (Among other things, some defective build environments
-  leak the Linux kernel's CONFIG_SYMBOLS into the system's standard #include
-  files.  We've experienced collisions before.)
----
 FEATURE_CLEAN_UP
   This is more an unresolved issue than a to-do item.  More thought is needed.
 
@@ -266,12 +236,7 @@ Minor stuff:
 ---
   unify progress_meter. wget, flash_eraseall, pipe_progress, fbsplash, setfiles.
 ---
-   support start-stop-daemon -d <chdir-path>
-
-Code cleanup:
-
-Replace deprecated functions.
-
+  support start-stop-daemon -d <chdir-path>
 ---
 vdprintf() -> similar sized functionality
 ---
@@ -296,8 +261,6 @@ vdprintf() -> similar sized functionality
   The first step would to generate a file/matrix what is already archived
   (also IPV6)
 
-* ntpdate/ntpd (see ntpclient and openntp for examples)
-
 * implement 'at'
 
 * rpcbind (former portmap) or equivalent
@@ -311,64 +274,3 @@ vdprintf() -> similar sized functionality
   most likely there is more
 
 * even more support for statistics: mpstat, iostat, powertop....
-
-
-Unicode work needed:
-
-Unicode support uses libc multibyte functions if LOCALE_SUPPORT is on
-(in this case, the code will also support many more encodings),
-or uses a limited subset of re-implemented multibyte functions
-which only understand "one byte == one char" and unicode.
-This is useful if you build against uclibc with locale support disabled.
-
-Unicode-dependent applets must call check_unicode_in_env() when they
-begin executing.
-
-Applet code may conditionalize on UNICODE_SUPPORT in order to use
-more efficient code if unicode support is not requested.
-
-Available functions (if you need more, implement them in libbb/unicode.c
-so that they work without LOCALE_SUPPORT too):
-
-int bb_mbstrlen(str) - multibyte-aware strlen
-size_t mbstowcs(wdest, src, n)
-size_t wcstombs(dest, wsrc, n)
-size_t wcrtomb(str, wc, wstate)
-int iswspace(wc)
-int iswalnum(wc)
-int iswpunct(wc)
-
-Applets which only need to align columns on screen correctly:
-
-ls - already done, use source as an example
-df
-dumpleases
-lsmod
-
-Applets which need to account for Unicode chars
-while processing the output:
-
-[un]expand
-fold
-man
-watch
-cut (-b and -c are currently the same, needs fixing)
-
-These applets need to ensure that unicode input
-is handled correctly (say, <unicode><backspace> sequence):
-
-getty, login
-rm -i
-unzip (overwrite prompt)
-
-Viewers/editors are more difficult (many cases to get right).
-libbb/lineedit.c is an example how to do it:
-
-less, most, ed, vi
-awk
-[ef]grep
-sed
-
-Probably needs some specialized work:
-
-loadkeys