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

[enh <enh%google.com@localhost>]

(reposting as plain text.)

On Fri, Aug 10, 2012 at 12:55 PM, enh <enh%google.com@localhost> wrote:
>
> (replying to myself so it doesn't look like i'm responding to any
> individual post.)
>
> thanks for all the replies. to summarize what i think i learned:
>
> * NetBSD would be a reasonable choice for my upstream.
>
> * there turn out to be a bunch of tests i'll be able to make use of.
> (that's exciting and unexpected.)
>
> * the libm situation is a little less clear; i might want to look at going
> with FreeBSD's libm. i'll worry about that later.
>
> i've made a small start by writing a script to automate generation of
> Android's NOTICE files from all the source files' copyright headers
> (https://android-review.googlesource.com/#/c/40685/), and by switching from
> our broken strxfrm(3) to NetBSD's in a way that should make it easier to add
> more unadulterated NetBSD files in future
> (https://android-review.googlesource.com/#/c/40729/).
>
> looking at the differences between NetBSD's inet_pton.c and Android's, i
> wonder if i can find some documentation on what portbefore.h and portafter.h
> are supposed to contain. my guess is that they're meant to help people like
> me do things like this.
>
>  -enh
>
> On Wed, Jul 25, 2012 at 3:14 PM, enh <enh%google.com@localhost> wrote:
>>
>> 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
>
>
>



--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
NIO or JNI questions? Mail me/drop by/add me as a reviewer.