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

["Jeremy C. Reed" <reed%reedmedia.net@localhost>]

Hello Elliott,

On Wed, 25 Jul 2012, enh wrote:

> * 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.

This list is good.

> * do the different BSD flavors have a shared upstream C library? it
> looks like they're divergent, so i'm guessing no.

They are maintained separately.  They offer some different APIs too.
Nevertheless, there may be some code sharing and ideas periodically.

> * is libm a special case? do you guys get that from some other
> upstream that i should be pulling from directly?

I don't think any upstream for libm has been used since original fdlibm 
use in mid 1990's. There have been various features pulled from FreeBSD, 
but NetBSD's libm is maintained by NetBSD.

> * 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!

A few reasons:

1) NetBSD has been working actively to create a large collection of 
unittests and regression tests. (I see around 800 tests with over 400 
source files for our standard libraries.) The developers policy is to 
provide unittests for new code. The developer community has at least a 
few automated test farms that automatically (and some manually) that 
report about regressions. (This reminds me that an extensive unittest 
suite was done for math libraries and and may need to be integrated.)

2) NetBSD has already began planning supporting feature-based 
distributions for our useful or popular standalone products. We have a 
lot of code used by others and we should make it easier to get it. This 
includes libc.

3) Other projects use NetBSD's libc and libm. For example, see one 
project which made a huge change: 
http://code.metager.de/source/history/minix/lib/libm/src/e_atanh.chttp://code.metager.de/source/history/minix/lib/libm/src/e_atanh.c
 
http://wiki.minix3.org/en/MinixReleases 
http://wiki.minix3.org/en/DevelopersGuide/PortingNetBSDUserland

(I recall hearing about an extensive test suite for libc done by the 
MINIX3 community, but I may be mistaken. Anyone have a pointer about 
that?)

4) NetBSD strives to be the go-to reference implementation for various 
operating system features. This is a common goal for many NetBSD 
developers.

> * 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.

I don't think anyone speaks for them all anymore.

> * 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.

http://www.netbsd.org/support/query-pr.html
http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd

Yes, please do share your suggestions, fixes, or bug reports.

> * 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?

I will let others answer this.  It probably is a case-by-case decision. 
But certainly NetBSD as a community does not hate or disagree with 
various extensions. I'd assume we'd try to do the best thing. Some of 
our libraries do specifically mimic GNU features.

(On that note ... it is not official yet and maybe won't happen, but 
there has been some agreement by both sides that NetBSD will take over 
the official maintainership for the suite for the your above named 
function.)

> * 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 NetBSD may be open to it case-by-case (see my notes above being 
a reference implementation while also planning to make standalone 
components easier to use by others).

> i think that's about it for now. thanks!

Thank you for using NetBSD code!