From c7cba1ae3bacb11de6a11df8c2fc98a69e423d7d Mon Sep 17 00:00:00 2001 From: Rob Landley Date: Sat, 13 Aug 2005 01:12:49 +0000 Subject: This is published from trunk, remove from 1.0 branch. --- busybox/docs/busybox.net/FAQ.html | 289 -------------------------------------- 1 file changed, 289 deletions(-) delete mode 100644 busybox/docs/busybox.net/FAQ.html (limited to 'busybox/docs/busybox.net/FAQ.html') diff --git a/busybox/docs/busybox.net/FAQ.html b/busybox/docs/busybox.net/FAQ.html deleted file mode 100644 index 8de06e6..0000000 --- a/busybox/docs/busybox.net/FAQ.html +++ /dev/null @@ -1,289 +0,0 @@ - - - -
-
- - - Full functionality requires Linux 2.2.x or better. A large fraction of the - code should run on just about anything. While the current code is fairly - Linux specific, it should be fairly easy to port the majority of the code - to support, say, FreeBSD or Solaris, or Mac OS X, or even Windows (if you - are into that sort of thing). - - -
-
- - - BusyBox in general will build on any architecture supported by gcc. - Kernel module loading for 2.2 and 2.4 Linux kernels is currently - limited to ARM, CRIS, H8/300, x86, ia64, x86_64, m68k, MIPS, PowerPC, - S390, SH3/4/5, Sparc, v850e, and x86_64 for 2.4.x kernels. - - With 2.6.x kernels, module loading support should work on all architectures. - - -
-
- - - uClibc and glibc are supported. People have been looking at newlib and - dietlibc, but they are currently considered unsupported, untested, or - worse. Linux-libc5 is no longer supported. If you require a small C - library, you should probably use uClibc. - - -
-
-
- - If you find a problem with BusyBox, please submit a detailed bug report to - the BusyBox mailing list at - busybox@mail.busybox.net. Please do not send private email to Erik - (the maintainer of BusyBox) asking for private help unless you are planning - on paying for consulting services. When we answer questions on the BusyBox - mailing list, it helps everyone, while private answers help only you... - -
- - If you find bugs, please submit a detailed bug report to the BusyBox mailing - list at busybox@mail.busybox.net. A well-written bug report should include a - transcript of a shell session that demonstrates the bad behavior and enables - anyone else to duplicate the bug on their own machine. The following is such - an example: - -
- To: busybox@mail.busybox.net - From: diligent@testing.linux.org - Subject: /bin/date doesn't work - - Package: BusyBox - Version: 1.00 - - When I execute BusyBox 'date' it produces unexpected results. - With GNU date I get the following output: - - $ date - Fri Oct 8 14:19:41 MDT 2004 - - But when I use BusyBox date I get this instead: - - $ date - illegal instruction - - I am using Debian unstable, kernel version 2.4.27 on a x86 system, - and the latest uClibc from CVS. Thanks for the wonderful program! - - -Diligent -- - Note the careful description and use of examples showing not only what BusyBox - does, but also a counter example showing what an equivalent GNU app does. Bug - reports lacking proper detail may never be fixed... Thanks for understanding. - -
-
- - Job control will be turned off since your shell can not obtain a controlling - terminal. This typically happens when you run your shell on /dev/console. - The kernel will not provide a controlling terminal on the /dev/console - device. Your should run your shell on a normal tty such as tty1 or ttyS0 - and everything will work perfectly. If you REALLY want your shell - to run on /dev/console, then you can hack your kernel (if you are into that - sortof thing) by changing drivers/char/tty_io.c to change the lines where - it sets "noctty = 1;" to instead set it to "0". I recommend you instead - run your shell on a real console... - - -
-
- - An easy method to build your own basic BusyBox based system, is to - follow these simple steps: -
-
- - You have not paid us a single cent and yet you still have the product of - many years of our work. We are not your slaves! We work on BusyBox - because we find it useful and interesting. If you go off flaming us, we - will ignore you. - - -
-
- - If you find that you need help with BusyBox, you can ask for help on the - BusyBox mailing list at busybox@mail.busybox.net. In addition to the BusyBox - mailing list, Erik (andersee), Manuel (mjn3) and others are known to hang out - on the uClibc IRC channel: #uclibc on irc.freenode.net. - -
- - Please do not send private email to Erik, Manuel, or the other BusyBox - contributors asking for private help unless you are planning on paying for - consulting services. - -
- - When we answer questions on the BusyBox mailing list, it helps everyone - since people with similar problems in the future will be able to get help - by searching the mailing list archives. Private help is reserved as a paid - service. If you need to use private communication, or if you are serious - about getting timely assistance with BusyBox, you should seriously consider - paying for consulting services. - -
- - - -
-
- - Sure! Now you have our attention! What you should do is contact Erik Andersen of CodePoet Consulting to bid - on your project. If Erik is too busy to personally add your feature, there - are many other active BusyBox contributors who will almost certainly be able - to help you out. Erik can contact them privatly, and may even let you to - post your request for services on the mailing list. - - -
-
- - Wow, that would be great! Erik personally pays for all the bandwidth, and - all servers used for busybox.net out of his own pocket. If you would like - to make a donation to help support BusyBox, and/or request features, you - can click here: - - -
-
- To conserve bytes it's good to know where they're being used, and the - size of the final executable isn't always a reliable indicator of - the size of the components (since various structures are rounded up, - so a small change may not even be visible by itself, but many small - savings add up). -
-- To examine a busybox binary with an eye to saving bytes, build an - optimized debug version and run the "nm" command against it, like so: -
-- make clean && make STRIPCMD=/bin/true && nm --size-sort busybox -
-- This gives a list of symbols and the amount of space allocated for - each one, sorted by size. (Note: do not enable CONFIG_DEBUG for this, - as that disables compiler optimization which is great for running gdb - but misleading when trying to figure out how much space each component - is really using under normal circumstances.) -
-