3 ms·

When Android was started, no embedded system of any kind used glibc. It's now 2019 and still none do. It's not GPL avoidance, it's just glibc being (a) huge (pa

When Android was started, no embedded system of any kind used glibc. It's now 2019 and still none do. It's not GPL avoidance, it's just glibc being (a) huge (pain) for all the wrong reasons.

andrekandre 7y ago
what parts of glibc make it trouble for embedded systems? is it the way it uses memory? or just “too large”?
- kllrnohj 7y ago
  glibc has a reputation for being bloated. Here's a post from 2002 of Linus complaining about it, for example: http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.html http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.ht... Independently of that glibc also has organizational issues. You see this in some major projects flipping back and forth on it, like Debian switching to EGLIBC in 2009 and then back to glibc in 2015. You continue to see this with the very slow (or outright rejection) adoption of new syscalls: https://lwn.net/Articles/655028/ https://lwn.net/Articles/655028/ It's important to remember glibc is not libc for Linux, and distinctly does not behave as such. If your platform is unapologetically Linux to the core, wouldn't you want something else that tracks the kernel API better? And it's not like Android was unique in not using glibc, either. The *BSD's don't, either.
  - geofft 7y ago
    The job of a libc involves a lot more than just tracking the kernel APIs: it's got a malloc implementation, string handling, userspace buffered I/O and formatting, locales (quite a bit more important on a phone targeted at consumers around the world than on servers whose sysadmins generally prefer messages in English to their native tongue anyway), user and group names and not just numeric IDs, DNS resolution, thread handling, math functions, etc. All of that is quite independent of your kernel and hewing closer to Linux doesn't help you with any of it - except maybe the thread stuff, and for that glibc is the standard pthread implementation for Linux so you're probably better off using it anyway since that's what the kernel developers expect. (In other words, libc is the C standard library, not the kernel's client library for its APIs.) Bloat in terms of amount of code is a confusing argument: you map libraries from disk, so you only use memory for the pages of code that have actually been read from disk and you only use one copy regardless of how many programs are running. You could add a function to glibc to print War and Peace to the screen and the only thing it would do is add a few megabytes of disk usage if nobody called it. Even on Android, disk is cheap. EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was intended for embedded use. The BSDs don't use glibc because of licensing concerns, not because they dislike glibc's bloat. (Their own libcs implement just as much, because programs use those features.) My claim upthread was that Android avoided glibc for licensing concerns, not for technical unsuitability; giving the BSDs as an example seems to agree with that argument.
    - kllrnohj 7y ago
      > locales (quite a bit more important on a phone targeted at consumers around the world than on servers whose sysadmins generally prefer messages in English to their native tongue anyway) This is part of where glibc's bloat comes from. Locales are important, yes, but when your libc's versions are bad and you have to ship an alternative anyway (icu4c), then the one in glibc is just pure, wasted bloat. But ignoring that aspect since not every program needs internationalization, this just becomes bloat in the libc. This is really not something a libc (or any standard library) should be handling. Even if it's just because it's an area that moves too fast for a standard library to typically keep up with, and needs a faster deployment cycle. > Bloat in terms of amount of code is a confusing argument: you map libraries from disk, so you only use memory for the pages of code that have actually been read from disk and you only use one copy regardless of how many programs are running. You could add a function to glibc to print War and Peace to the screen and the only thing it would do is add a few megabytes of disk usage if nobody called it. Not entirely true. You're assuming everyone is using a single shared version, which isn't universally true. Some need static for reasons, and there's multiple shared versions not one for 32bit vs. 64bit or strict versioning requirements. Also not all functions are free to add. __attribute__((constructor)) exists, after all, and is hugely not free of course. Similarly pages are not purely loaded on-demand, they are prefetched. Depending on where you've added those functions and how the resulting layout happened, you may now be getting fewer prefetch hits than you did before. > Even on Android, disk is cheap. No, not really. Today is the size of glibc less important? Maybe, sure. Was that true back in the Android 1.0 days? No. There are some numbers here: http://www.etalabs.net/compare_libcs.html http://www.etalabs.net/compare_libcs.html glibc is stonking massive compared to what a C library really needs to do and, critically, has the largest minimum dirty page sizes. That's a shared library creating not-shared memory usage. > EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was intended for embedded use. Someone forked GLIBC and ripped a bunch of stuff out and you're taking that as a good sign GLIBC was intended for embedded use? What?
      - geofft 7y ago
        > Someone forked GLIBC and ripped a bunch of stuff out and you're taking that as a good sign GLIBC was intended for embedded use? What? If that were what happened, then you'd have an argument, but eglibc contained more than glibc did (the primary motivator was that glibc refused to support architectures that the maintainer didn't like; they also had patches to support compiling things out, but that's more source code and certainly isn't ripping anything out). If you don't know this history I have trouble taking the rest of your argument seriously.
geofft 7y ago
Sure, but glibc being bloated doesn't explain why they didn't take working, tested code from glibc and cobble together a stripped-down version instead of starting entirely from scratch. You can absolutely fork a version of glibc that pulls out things like dynamic NSS backends, sunrpc, nscd, etc. even if it won't be accepted upstream, and it'll get you a working libc way faster than writing your own cleanroom libc. (With the important bonus of working with existing software that expects glibc and not just a pure POSIX libc, of which there's quite a bit!) Also, Android isn't "embedded" in the sense you're thinking of: the first Android phone had a 528 MHz ARM processor with DSP coprocessor, 256 MB boot disk + storage on microSD, and 192 MB RAM, which was quite a bit more powerful than e.g. the computer I had in 1995 (75 MHz Pentium, 16 MB RAM, 1 GB disk) that ran Red Hat Linux 6 just fine and definitely far more powerful than the machines glibc was originally developed on. So glibc was certainly not too big for Android. And plenty of "embedded systems" along the lines of Android did / do in fact use glibc, from OpenEmbedded to Emdebian to Maemo. Heck, there was even a project called "embedded glibc" (EGLIBC), which is now the official glibc.
arebours 7y ago
This is not true. I've worked for two separate companies making soft for STBs and used glibc in both.

When Android was started, no embedded system of any kind used glibc. It's now 2019 and still none do. It's not GPL avoidance, it's just glibc being (a) huge (pain) for all the wrong reasons.

andrekandre 7y ago

what parts of glibc make it trouble for embedded systems? is it the way it uses memory? or just “too large”?

kllrnohj 7y ago
glibc has a reputation for being bloated. Here's a post from 2002 of Linus complaining about it, for example: http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.html http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.ht... Independently of that glibc also has organizational issues. You see this in some major projects flipping back and forth on it, like Debian switching to EGLIBC in 2009 and then back to glibc in 2015. You continue to see this with the very slow (or outright rejection) adoption of new syscalls: https://lwn.net/Articles/655028/ https://lwn.net/Articles/655028/ It's important to remember glibc is not libc for Linux, and distinctly does not behave as such. If your platform is unapologetically Linux to the core, wouldn't you want something else that tracks the kernel API better? And it's not like Android was unique in not using glibc, either. The *BSD's don't, either.
- geofft 7y ago
  The job of a libc involves a lot more than just tracking the kernel APIs: it's got a malloc implementation, string handling, userspace buffered I/O and formatting, locales (quite a bit more important on a phone targeted at consumers around the world than on servers whose sysadmins generally prefer messages in English to their native tongue anyway), user and group names and not just numeric IDs, DNS resolution, thread handling, math functions, etc. All of that is quite independent of your kernel and hewing closer to Linux doesn't help you with any of it - except maybe the thread stuff, and for that glibc is the standard pthread implementation for Linux so you're probably better off using it anyway since that's what the kernel developers expect. (In other words, libc is the C standard library, not the kernel's client library for its APIs.) Bloat in terms of amount of code is a confusing argument: you map libraries from disk, so you only use memory for the pages of code that have actually been read from disk and you only use one copy regardless of how many programs are running. You could add a function to glibc to print War and Peace to the screen and the only thing it would do is add a few megabytes of disk usage if nobody called it. Even on Android, disk is cheap. EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was intended for embedded use. The BSDs don't use glibc because of licensing concerns, not because they dislike glibc's bloat. (Their own libcs implement just as much, because programs use those features.) My claim upthread was that Android avoided glibc for licensing concerns, not for technical unsuitability; giving the BSDs as an example seems to agree with that argument.
  - kllrnohj 7y ago
    > locales (quite a bit more important on a phone targeted at consumers around the world than on servers whose sysadmins generally prefer messages in English to their native tongue anyway) This is part of where glibc's bloat comes from. Locales are important, yes, but when your libc's versions are bad and you have to ship an alternative anyway (icu4c), then the one in glibc is just pure, wasted bloat. But ignoring that aspect since not every program needs internationalization, this just becomes bloat in the libc. This is really not something a libc (or any standard library) should be handling. Even if it's just because it's an area that moves too fast for a standard library to typically keep up with, and needs a faster deployment cycle. > Bloat in terms of amount of code is a confusing argument: you map libraries from disk, so you only use memory for the pages of code that have actually been read from disk and you only use one copy regardless of how many programs are running. You could add a function to glibc to print War and Peace to the screen and the only thing it would do is add a few megabytes of disk usage if nobody called it. Not entirely true. You're assuming everyone is using a single shared version, which isn't universally true. Some need static for reasons, and there's multiple shared versions not one for 32bit vs. 64bit or strict versioning requirements. Also not all functions are free to add. __attribute__((constructor)) exists, after all, and is hugely not free of course. Similarly pages are not purely loaded on-demand, they are prefetched. Depending on where you've added those functions and how the resulting layout happened, you may now be getting fewer prefetch hits than you did before. > Even on Android, disk is cheap. No, not really. Today is the size of glibc less important? Maybe, sure. Was that true back in the Android 1.0 days? No. There are some numbers here: http://www.etalabs.net/compare_libcs.html http://www.etalabs.net/compare_libcs.html glibc is stonking massive compared to what a C library really needs to do and, critically, has the largest minimum dirty page sizes. That's a shared library creating not-shared memory usage. > EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was intended for embedded use. Someone forked GLIBC and ripped a bunch of stuff out and you're taking that as a good sign GLIBC was intended for embedded use? What?
    - geofft 7y ago
      > Someone forked GLIBC and ripped a bunch of stuff out and you're taking that as a good sign GLIBC was intended for embedded use? What? If that were what happened, then you'd have an argument, but eglibc contained more than glibc did (the primary motivator was that glibc refused to support architectures that the maintainer didn't like; they also had patches to support compiling things out, but that's more source code and certainly isn't ripping anything out). If you don't know this history I have trouble taking the rest of your argument seriously.

geofft 7y ago

Sure, but glibc being bloated doesn't explain why they didn't take working, tested code from glibc and cobble together a stripped-down version instead of starting entirely from scratch. You can absolutely fork a version of glibc that pulls out things like dynamic NSS backends, sunrpc, nscd, etc. even if it won't be accepted upstream, and it'll get you a working libc way faster than writing your own cleanroom libc. (With the important bonus of working with existing software that expects glibc and not just a pure POSIX libc, of which there's quite a bit!) Also, Android isn't "embedded" in the sense you're thinking of: the first Android phone had a 528 MHz ARM processor with DSP coprocessor, 256 MB boot disk + storage on microSD, and 192 MB RAM, which was quite a bit more powerful than e.g. the computer I had in 1995 (75 MHz Pentium, 16 MB RAM, 1 GB disk) that ran Red Hat Linux 6 just fine and definitely far more powerful than the machines glibc was originally developed on. So glibc was certainly not too big for Android. And plenty of "embedded systems" along the lines of Android did / do in fact use glibc, from OpenEmbedded to Emdebian to Maemo. Heck, there was even a project called "embedded glibc" (EGLIBC), which is now the official glibc.

arebours 7y ago

This is not true. I've worked for two separate companies making soft for STBs and used glibc in both.