4 ms·

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.

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.