summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorEric Andersen <andersen@codepoet.org>2003-09-07 05:30:52 +0000
committerEric Andersen <andersen@codepoet.org>2003-09-07 05:30:52 +0000
commitbfed1e760cc46932681930bb05603257802e316a (patch)
tree32e16a6f1fedc31568e44cd529b7d14c97c77a17 /docs
parent8246a4abd5210bd9257f13a491697aeb81284c02 (diff)
More FAQ updates
Diffstat (limited to 'docs')
-rw-r--r--docs/uclibc.org/FAQ.html77
1 files changed, 48 insertions, 29 deletions
diff --git a/docs/uclibc.org/FAQ.html b/docs/uclibc.org/FAQ.html
index e9e3019cc..53cd52f88 100644
--- a/docs/uclibc.org/FAQ.html
+++ b/docs/uclibc.org/FAQ.html
@@ -85,7 +85,7 @@ to the uClibc home page.</a>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- Initially, the project began since the GNU C library lacks support for
+ Initially, the project began since the GNU C library lacked support for
MMU-less systems, and because glibc is very large. The GNU C library is
designed with a very different set of goals then uClibc. The GNU C library
is a great piece of software, make no mistake. It is compliant with just
@@ -109,38 +109,46 @@ to the uClibc home page.</a>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- uClibc has been designed from the ground up to be a C library for embedded
- Linux. We don't need to worry about things like MS-DOS support, or BeOS,
- or AmigaOs any other system. This lets us cut out a lot of complexity and
- very carefully optimize for Linux. By very careful design, we can also
- take a few shortcuts.
-<!-- FIXME
- For example, glibc's stdio code (handling things
- like printf, scanf, fopen, etc) has been evolved over many years by
- patching various bits of additional functionality as needed. uClibc's
- stdio code was written by just one person, and was carefully designed from
- the outset to comply with the latest standards while carefully reusing code
- and being as small and configurable as possible, In this way, uClibc's
- stdio code...
-
- There are many similar examples.
--->
- In other cases, uClibc
- leaves certain features (such as full C99 Math library support, IPV6, and
- RPC support) disabled by default. Those features can be enabled for people
- that need them, but are otherwise disabled to save space.
+ uClibc and glibc have different goals. glibc strives for features
+ and performance, and is targeted for desktops and servers with
+ (these days) lots of resources. It also strives for ABI stability.
<p>
- Glibc is a general purpose C library, and so as policy things are optimized
- for speed. Most of uClibc's routines have been very carefully written to
- optimize them for size instead.
+ On the other hand, the goal of uClibc is to provide as much functionality
+ as possible in a small amount of space, and it is intended primarily for
+ embedded use. It is also highly configurable in supported features, at the
+ cost of ABI differences for different configurations. uClibc has been
+ designed from the ground up to be a C library for embedded Linux. We don't
+ need to worry about things like MS-DOS support, or BeOS, or AmigaOs any
+ other system. This lets us cut out a lot of complexity and very carefully
+ optimize for Linux.
+
+ <p>
+
+ In other cases, uClibc
+ leaves certain features (such as full C99 Math library support, wordexp,
+ IPV6, and RPC support) disabled by default. Those features can be enabled
+ for people that need them, but are otherwise disabled to save space.
+
+ <p>
+
+ Some of the space savings in uClibc is obtained at the cost of performance,
+ and some is due to sacrificing features. Much of it comes from aggressive
+ refactoring of code to eliminate redundancy. In regards to locale data,
+ elimination of redundant data storage resulted in substantial space
+ savings. The result is a libc that currently includes the features needed
+ by nearly all applications and yet is considerably smaller than glibc. To
+ compare "apples to apples", if you take uClibc and compile in locale data
+ for about 170 UTF-8 locales, then uClibc will take up about 570k. If you
+ take glibc and add in locale data for the same 170 UTF-8 locales, you will
+ need over 30MB!!!
<p>
The end result is a C library that will compile just about everything you
throw at it, that looks like glibc to application programs when you
- compile, but is many times smaller.
+ compile, and is many times smaller.
@@ -156,6 +164,8 @@ to the uClibc home page.</a>
If you are building an embedded Linux system and you are tight on space, then
using uClibc instead if glibc may be a very good idea.
+ <p>
+
If you are trying to build a huge fileserver for your company that will
have 12 Terabytes of storage, then using glibc may make more sense.
Unless, for example, that 12 Terabytes will be Network Attached Storage
@@ -201,7 +211,7 @@ to the uClibc home page.</a>
<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
<B>
- Can I use it on my desktop i386 system?
+ Can I use it on my x86 development system?
</B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
@@ -403,9 +413,18 @@ to the uClibc home page.</a>
<p>
- These days, uClibc is being developed and enhanced by Erik Andersen of
- <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> along
- with the rest of the embedded Linux community.
+ In particular, around the end of 2000, Manuel Novoa III got involved with
+ uClibc. One of his first contributions was the original gcc wrapper.
+ Since then, he has written virtually all of the current uClibc stdio, time,
+ string, ctype, locale, and wchar-related code, as well as much of stdlib
+ and various other bits throught the library.
+
+ <p>
+
+ These days, uClibc is being developed and enhanced by Erik Andersen
+ and Manuel Novoa III of
+ <a href="http://codepoet-consulting.com/">CodePoet Consulting</a>
+ along with the rest of the embedded Linux community.