tech-userlevel archive

getting Android's bionic C library back in sync with upstream

To : tech-userlevel%netbsd.org@localhost

: Subject : getting Android's bionic C library back in sync with upstream

: From : enh <enh%google.com@localhost>

: Date: Wed, 25 Jul 2012 15:14:49 -0700

hi, my name's Elliott, and i'm a C library maintainer. as you may be aware, Android's C library "bionic" is a hybrid of code from different sources --- there's stuff like the pthreads implementation that's home grown, but there's a lot of FreeBSD, NetBSD, and OpenBSD code in there too. NetBSD files aren't from a single NetBSD release; hell, they're not even necessarily from _any_ release. i found a bug in getcwd (iirc) that had been fixed upstream in like 1996, but we had some random old version of that file. (and similar for the other BSD flavors.) i'd like to get bionic to a point where we have one upstream (that is, i'd like to get all my upstream code from FreeBSD _or_ NetBSD _or_ OpenBSD, not a mixture), and where we can easily track that upstream. so i have a few questions: * is this an appropriate mailing list for my questions? if not, please stop reading and (if you know) tell me who i should bother instead. * do the different BSD flavors have a shared upstream C library? it looks like they're divergent, so i'm guessing no. * is libm a special case? do you guys get that from some other upstream that i should be pulling from directly? * if i'm choosing just one flavor, would NetBSD be a good flavor for me to go with? i realize you're likely to be biased, but if you can think of some reason why i should be looking at one of the other BSDs instead, please let me know! * who speaks for the BSD C library community? everyone knows the glibc names, but i'm afraid i'm ignorant when it comes to BSD. * when i have bugs that aren't fixed upstream, where's the best place for me to submit patches? there's a getopt_long bug, for example, that's been reported to me that appears to be broken upstream too (https://android-review.googlesource.com/#/c/37620/). for obvious reasons, i'd prefer to fix stuff upstream and cherry-pick the fix into bionic afterwards. * how do you feel about GNU extensions? one problem i have is that i'm often faced with code ported from Linux that expects to run on glibc. so when glibc's freeaddrinfo(3) accepts and ignores NULL like most of the other free-like functions do, it causes trouble for me that the BSD freeaddrinfo(3) blows up in this case. would you accept patches for GNU extensions, or is that anathema to you? * how do you feel about #ifdef ANDROID and/or #ifdef __linux__? (i realize this might sound crazy, but you _are_ known for your focus on portability!) sometimes i "fork" a file for no good reason other than it refers to something linux doesn't have. for example, in https://android-review.googlesource.com/#/c/37804/1 i had to add #ifs to getnameinfo.c because linux doesn't have AF_LINK. other than that, the NetBSD getnameinfo works fine on linux. obviously my life would be easier if i could get my linux portability stuff upstream. (i realize there might be a continuum where something like that change might be acceptable but something really invasive might not. for now i'm just interested in principle. so i guess a related question would be whether you'd consider patches that moved non-portable stuff into separate files?) i think that's about it for now. thanks! -enh