[Toybox] Android sitrep

[Rob Landley]

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

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?

(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