[Toybox] cleaning out deprecated code

[enh]

On Thu, Aug 22, 2019 at 11:34 AM Rob Landley <rob at landley.net> wrote:
>
> On 8/21/19 6:02 PM, enh wrote:
> >>>> Also, in toybox getconf.c I just bumped into:
> >>>>
> >>>> // When NDK r19 ships in 2018Q4, switch to _SC_UIO_MAXIOV.
> >>>> // (Until then use this workaround for musl.)
> >>>> #ifndef UIO_MAXIOV
> >>>> #define UIO_MAXIOV 1024
> >>>> #endif
> >>>>
> >>>> Is it safe to yank that now?
> >>>
> >>> yes, sorry for forgetting about that. r20's out now too!
> >>
> >> Woot.

(i hadn't forgotten, it just turned out a bit more awkward than i'd
expected because of the mac. i've thought about it and tested
everywhere, and sent a patch that i think makes sense [with details in
the commit message].)

> Oh, while we're at it, in main.c function main():
>
>   // Up to and including Android M, bionic's dynamic linker added a handler to
>   // cause a crash dump on SIGPIPE. That was removed in Android N, but adbd
>   // was still setting the SIGPIPE disposition to SIG_IGN, and its children
>   // were inheriting that. In Android O, adbd is fixed, but manually asking
>   // for the default disposition is harmless, and it'll be a long time before
>   // no one's using anything older than O!
>   if (CFG_TOYBOX_ON_ANDROID) signal(SIGPIPE, SIG_DFL);
>
> The 7 year time horizon is toybox policy, but not _android_ policy? Are we going
> to be building a lot of new toybox for old android devices?

_i_ certainly don't plan on it :-)

> (I'd love to say
> yes, but how far back does the NDK support?

currently API level 16, Jelly Bean. that's the oldest release that has
full PIC/PIE support, so supporting older than that is a large cost
for basically zero market share.

> And if we DO build new toybox for
> older android devices, I need to add some regression test targets and set up a
> build thingy. I have NO clue how to do the magic selinux annotation outside of
> AOSP. I've never actually rooted an android device; downloading a random third
> party binary to install a rootkit _for_ me always seems... I haven't even
> installed the steam dpkg on my laptop because the URL to the binary on their
> servers ISN'T HTTPS. Grrr...)
>
> Anyway, Oreo shipped 2 years (as of yesterday), pie is out... how long should
> this code stay there?

up to you. i certainly wouldn't notice if it was removed today. i
don't know how many random folks are building toybox prebuilts to run
on old devices.

if your question is actually about in numbers, O is still < half of
the real world (and Q isn't even out yet, even if i put my pencil down
and moved on to R a while ago):
https://developer.android.com/about/dashboards

> (I'm thinking of walking through main() as part of my talk in 2 hours, and saw
> this and went "Is that still really needed? If so, how long?")
>
> We should probably have notes to schedule the removal of stuff like this (as you
> did for the NDK thing above), so I can search for them as part of release prep.
> (I have a checklist, I can add that...)
>
> When would THIS one be scheduled for removal?

depends on who you think the users are. from AOSP's perspective, we
can remove this today. it's really only to help folks targeting old
devices. (but as long as neither you nor i actually have a continuous
build targeting those devices, let alone running the tests, we don't
really know what state that's in.)

maybe i should build a static toybox binary as part of the regular
build, though? i could make it available as one of the downloadable
artifacts (https://source.android.com/setup/build/dashboard) and you
could update the readme to point folks looking for an Android binary
there (with a suitable "buyer beware --- not tested" warning).

> (Android S or so? Given that N
> wasn't "Nutella" I'm assuming S won't be Skittles. Kit-kat was a one-off then.
> I'm guessing the lawyers were Unhappy. 7 years from Not-Nutella would be August
> 21, 2024, which seems a bit long even to me.)

K and O (Oreo) were the only commercial tie-ins. it was announced
today that "Q" will be publicly known as "Android 10" with no
corresponding dessert name. but engineering will still call successive
releases R, S, etc (or API level 31, 32, etc, though that's a bit
riskier because -- as you can see from the fact that we're already >26
-- we've sometimes burned more than one API level per dessert).

> (P.S. Yeah, I meant to get a release out before my talk. Didn't happen. Try
> again this weekend...)

don't forget my couple of outstanding patches :-)

> Rob