[Toybox] Android sitrep

[enh]

On Tue, Oct 15, 2019 at 10:56 PM Rob Landley <rob at landley.net> wrote:
>
> On 10/10/19 8:52 PM, enh wrote:
> > On Sun, Oct 6, 2019 at 11:38 AM Rob Landley <rob at landley.net> wrote:
> >> Where is this packaging done in AOSP? (I can dig my way to it eventually, but
> >> you'd probably know off the top of your head. :)
> >
> > system/sepolicy/private/file_contexts
>
> *blink*
>
> *blink* *blink*
>
> Ah, system/sepolicy has a README, maybe I should start there. (I wonder what the
> .te extension stands for? Hmmm... the note at the end mentions setool, which I'm
> guessing is prebuilts/python/linux-x86/2.7.5/lib/python2.7/site-packages/setools
> which doesn't ahve a README... ah, but
> https://github.com/SELinuxProject/setools/blob/master/README.md does and no I'm
> not looking to _analyze_ the policy, I'm trying to find out what tool actually
> makes the resulting filesystem...
>
> Sigh. Google keeps bringing up stuff like
> https://www.oreilly.com/library/view/embedded-android/9781449327958/ch04.html
> which is 7 years old and talks about how closely the build is tied to a specific
> version of gnu make. :)
>
> Eh, poke at it later.
>
> >>> i can tell you already that one of the issues is going to be xargs -P
> >>> --- i almost sent you a patch last week that made -P a no-op (given
> >>> that the docs say "up to ... processes"); i don't know whether it
> >>> actually makes a difference to build times.
> >>
> >>   While  xargs  is
> >>   running,  you  can send its process a SIGUSR1 signal to increase
> >>   the number of commands to run simultaneously, or  a  SIGUSR2  to
> >>   decrease  the number.
> >>
> >> Seriously?...
> >> Anyway, I might whip up an xargs -P if it's quick and I get a gap, but this
> >> SIGUSR increment/decrement thing is kind of _conceptually_ silly? (What... why...?)
>
> My xargs is dirty from a half-finished cleanup after the last patch I merged
> (the xopen of /dev/tty would fail _after_ the fork, potentially repeatedly), and
> you've sent me two more patches, so I shouldn't open that can of worms now I
> expect. :)
>
> > i don't know of anyone who wants the signal nonsense. actually, if you
> > think you can get the hard-coded -P 8 removed from the kernel, i think
>
> Ah, you use the header archive and I use the "just install them in the new
> directory" variant (which is a script I wrote as part of the perl removal
> stuff). That's why I hadn't noticed.
>
> > we could all forget about this. (the scary part is that searching all
> > the source available to me internally, -P 8 is basically the only use
> > of -P. there's the odd pointless -P 1, and one -P 100, but presumably
> > everyone's copy & pasted 8 from somewhere? too high for my MacBook Pro
> > which starts to melt around 4, and too low for my desktop, which can't
> > count that low.)
> >
> > i do wonder how long it would take for anyone to notice if we made -P
> > a no-op (and am very disappointed with myself that i didn't do that
> > long ago).
>
> I could just do that. (This is _supposed_ to be iobound, what are they doing
> that -P 8 helps? Invoking perl. Oh JOY. More perl to remove from the kernel
> build! And the -n1 means THEY DON'T KNOW HOW TO USE FIND... sigh.)

yeah, i sent you that patch too the other day if you do want to go the
easy route. like i said, as far as i could find from searching, most
uses of -P were to explicitly set it to 1.

this is one reason why i like that toybox --help tries to be nice and
clear about what the defaults are. i suspect the folks who wrote -P1
learned xargs from --help and were worried by

  -P, --max-procs=MAX-PROCS    run at most MAX-PROCS processes at a time

but didn't bother/know how to experiment.

> Grumble grumble dowanna kernel tangent. Can't somebody ELSE remove this perl?
> Seriously, what is this:
>
> # Remove comments except SDPX lines
> find $cpio_dir -type f -print0 |
>         xargs -0 -P8 -n1 perl -pi -e 'BEGIN {undef $/;};
> s/\/\*((?!SPDX).)*?\*\///smg;'
>
> This is
>
>   find $cpio_dir -type f -exec sed -i "something" {} \;
>
> isn't it? I mean I could convert the _perl_ if I wanted to but... perl? Really?
>
> Sigh, what's the "something". Ok, -p is "print loop" and -i is same as sed -i, I
> think "BEGIN {undef $/;}; is perl noise here, and then you have the s//smg. What
> does /smg mean? Let's see...
>
> https://perldoc.perl.org/perlop.html#Regexp-Quote-Like-Operators
>
> g is the same as sed s///g
>
> s means "treat string as single line" and m means "treat string as multiple
> lines"...? Seriously, perl? This is your idea of documentation?

basically, this is about ^ and $, and whether they match start/end of
_line_ or start/end of _input_. (one sad thing about Android's switch
to OpenJDK is that my docs for java.util.regex.Pattern were lost. IMHO
they were the clearest concise Perl-compatible regex docs around.)

> (Oh, perl 6 has been renamed to "Raku". I wonder what they'll rename Python 3 to?)
>
> Sigh. Not working this out at 1am.
>
> >> [a month later, still no release out. Yesterday I plugged toybox into the old
> >> aboriginal linux build again and this time I got most of the way through the gcc
> >> build, at which point the tar "no ../ files outside this directory" check is
> >> false positiving on "./" for some reason, gotta track that down. All the corner
> >> cases, gotta constantly regression test, old builds are a good way to do that.
> >> They test stuff I'd never think off...]
> >
> > releases have to be time-based or feature-based, you can't have both :-)
>
> I know, I know. I'm overdue.
>
> >>> but i'm not sure how many people
> >>> actually build it themselves rather than just suffer whatever happened
> >>> to be on whatever device they have.
> >>
> >> Given how many people are still sticking busybox on devices, I'd expect there's
> >> a demand for newer toybox binaries on older systems. (Especially if I get the
> >> rest of the 1.0 roadmap sorted.)
> >
> > aren't busybox users folks who've rooted their devices? so they can
> > just use the latest toybox anyway?
>
> Exactly. If you're going to root your device, I'd like to make installing
> current _toybox_ on it a good option.
>
> Rob