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

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Hello Elliott,

enh <enh%google.com@localhost> wrote:
> hi, my name's Elliott, and i'm a C library maintainer.
> 

Thanks for contacting us.

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

Yes, tech-userlevel is a right place for NetBSD's libc discussions.

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

There is no single BSD libc upstream and, as you already noted, code has
diverged.  However, we do sync some fixes or changes amongst each other.

If you are interested in using libc on platforms like ARM, MIPS or others,
I would say NetBSD's libc is most tested and reliable in this respect, but
as you already noted - keep in mind that we are probably biased.. :)

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

The best way would be to submit a PR in our GNATS tracking system:

http://www.netbsd.org/support/send-pr.html

You are also welcome to send and discuss the patches in the mailing
lists, such as this one.

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

Depends.  Such discussions are usually a little bit controversial.
I think it would often be case-by-case basis.  If the extension is quite
reasonable - why not?  If the only reason is "just because it is in
glibc", then it might be difficult for us to accept such patch.

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

It is a bit crazy, but on the other hand, Minix project is using various
parts of NetBSD's libc (and userland) and some developers on our side are
working and cooperating with them.

There are also some intentions to provide parts of our libc (such as
red-black tree and radix/patricia tree implementations, CDB interface,
hashes, etc) for 3rd parties under a separate library (or libraries).
This project/idea has not materialised yet, though.

For a closer cooperation, you may contact our Board - I am sure they
will be open to discuss and look for solutions.

-- 
Mindaugas