+Portability:
+
+ Busybox is developed and tested on Linux 2.4 and 2.6 kernels, compiled
+ with gcc (the unit-at-a-time optimizations in version 3.4 and later are
+ worth upgrading to get, but older versions should work), and linked against
+ uClibc (0.9.27 or greater) or glibc (2.2 or greater). In such an
+ environment, the full set of busybox features should work, and if
+ anything doesn't we want to know about it so we can fix it.
+
+ There are many other environments out there, in which busybox may build
+ and run just fine. We just don't test them. Since busybox consists of a
+ large number of more or less independent applets, portability is a question
+ of which features work where. Some busybox applets (such as cat and rm) are
+ highly portable and likely to work just about anywhere, while others (such as
+ insmod and losetup) require recent Linux kernels with recent C libraries.
+
+ Earlier versions of Linux and glibc may or may not work, for any given
+ configuration. Linux 2.2 or earlier should mostly work (there's still
+ some support code in things like mount.c) but this is no longer regularly
+ tested, and inherently won't support certain features (such as long files
+ and --bind mounts). The same is true for glibc 2.0 and 2.1: expect a higher
+ testing and debugging burden using such old infrastructure. (The busybox
+ developers are not very interested in supporting these older versions, but
+ will probably accept small self-contained patches to fix simple problems.)
+
+ Some environments are not recommended. Early versions of uClibc were buggy
+ and missing many features: upgrade. Linking against libc5 or dietlibc is
+ not supported and not interesting to the busybox developers. (The first is
+ obsolete and has no known size or feature advantages over uClibc, the second
+ has known bugs that its developers have actively refused to fix.) Ancient
+ Linux kernels (2.0.x and earlier) are similarly uninteresting.
+
+ In theory it's possible to use Busybox under other operating systems (such as
+ MacOS X, Solaris, Cygwin, or the BSD Fork Du Jour). This generally involves
+ a different kernel and a different C library at the same time. While it
+ should be possible to port the majority of the code to work in one of
+ these environments, don't be surprised if it doesn't work out of the box. If
+ you're into that sort of thing, start small (selecting just a few applets)
+ and work your way up.
+
+ In 2005 Shaun Jackman has ported busybox to a combination of newlib
+ and libgloss, and some of his patches have been integrated.
+
+Supported hardware:
+
+ BusyBox in general will build on any architecture supported by gcc. We
+ support both 32 and 64 bit platforms, and both big and little endian
+ systems.
+
+ Under 2.4 Linux kernels, kernel module loading was implemented in a
+ platform-specific manner. Busybox's insmod utility has been reported to
+ work under ARM, CRIS, H8/300, x86, ia64, x86_64, m68k, MIPS, PowerPC, S390,
+ SH3/4/5, Sparc, v850e, and x86_64. Anything else probably won't work.
+
+ The module loading mechanism for the 2.6 kernel is much more generic, and
+ we believe 2.6.x kernel module loading support should work on all
+ architectures supported by the kernel.
projects / oweals / busybox.git / blobdiff