[Toybox] Android .config pondering.

[enh]

On Wed, May 4, 2022 at 8:15 PM Rob Landley <rob at landley.net> wrote:
>
> So I thought there should probably be a "make android_defconfig" target even if
> android isn't using it, just so I have an easier time tracking stuff. Except
> android has three configs: device, linux, and mac.

meh, like i always say, i think it's a sensible division of
responsibilities for you to worry about "does it work on debian?" and
android (and to a lesser, more "good guy greg" extent, mac) is my
problem?

> The android .config-mac the output of "make macos_defconfig" differing seems
> like a "me" problem (I should update my macos_defconnfig, and ideally I'd get an
> ssh into a mac box so I can see what actually builds and passes its tests. I
> could kinda hack the github build stuff in a fork to do that maybe? Rather a lot
> of iteration required though, unless maybe "make change" works on mac...)

iirc the reason they differ is that macos_defconfig is "everything
that passes the tests on a mac [the last time enh ran all the tests on
a mac]" whereas the android mac config is basically "the intersection
of macos_defconfig and android's _linux_ config".

> But the other two are... kinda confusing? The device (android) config has a lot
> of stuff the linux (build) one does not: acpi, base64, blkdiscard, blkid,
> blockdev, cal, chattr, chcon, chgrp, chown, chroot, chrt, cksum, clear, devmem,
> df, dmesg, expand, fallocate, false, file, flock, fmt, freeramdisk, free,
> fsfreeze, fsync, getenforce, getfattr, groups, gunzip, help, hwclock, i2c*,
> iconv, ifconfig, inotifyd, insmod, ionice, iorenice, iotop, kill, killall,
> load_policy, logname, log, losetup, lsattr, lsmod, lsof, lspci, lsusb, makedevs,
> mkfifo, mknod (twice?), mkswap, modinfo, modprobe, more, mount, mountpoint,
> nbd_client, netcat, netstat, nice, nohup, nsenter, partprobe, pidof, ping,
> ping6, pivot_root, pmap, printenv, pwdx, readelf, renice, restorecon, rev,
> rfkill, rmmod, rtcwake, runcon, sendevent, setenforce, setfattr, sha224sum,
> sha384sum, split, strings, stty, swapoff, swapon, sync, sysctl, tac, taskset
> (twice), time, top, traceroute, tty, tunctl, uclampset, ulimit, umount, unlink,
> unshare, uptime, usleep, uudecode, uuencode, uuidgen, vconfig, vi, vmstat,
> watch, and yes.

yeah, so for "android" my policy (to the extent there's any kind of
policy!) is basically "does it pass the tests on android?". if it
does, meh, ship it! someone might find it useful. there's a slightly
higher bar for whether or not it gets a symlink (which is actually a
separate list in the .bp file) --- but that's a lot more vague,
something like "does enh think this is either (a) in a good enough
state that we can realistically support it effectively or (b)
sufficiently useful that 'half an eye is better than no eye' and we
should make it easily available anyway, and deal with issues as they
arrive?".

> In fact only two symbols are enabled in the linux host but NOT the device:
> CONFIG_TOYBOX_LSM_NONE just means selinux support was NOT selected, and
> CONFIG_TOYBOX_SUID... can't work in the AOSP build? (Not only does the android
> build not run as root, but it doesn't CLONE as root either, meaning the toybox
> binary can't be installed suid root, so never has any privileges to drop.)

those will just be historical accidents. i can't actually remember
whether i started the two host configs from the android config, or
from separate defconfig/macos_defconfig runs. (there's probably stuff
in the files that doesn't exist any more, like the recent CATV
removals. a script to check for such things wouldn't be useless :-) )

> I guess this means I should use the device .config?

if your aim is "build and test what android ships on the device", yes.

if your aim is "build and test what android uses on the host to
_build_ android", you want the linux config.

(and if you're really not-so-secretly interested in "what i'd need to
build android on android", you'd still just need the linux config :-)
)

> (It sounds like what
> .config-linux wants is everything built but only certain symlinks populated?
> Which I guess is a dependency tracking thing?)

no, historically the linux config is "what does the AOSP build need?".
that's a much smaller set than "full" toybox.

that said, i am quite tempted to just add "all the stuff from posix/"
to the linux set. but the rate at which i get asked to add missing
stuff (usually by the folks building the _kernel_ than folks building
AOSP, because AOSP is locked down by default, and you can't just
"accidentally" add a dependency on a new host tool) is so low that
it's just not been worth it. (and especially not worth dealing with
the can of worms that is "aye, but you only have one directory of
symlinks for prebuilts/build-tools and if you add something there
'just because' then it [aiui] automatically gets made available for
build rules, which is probably something i shouldn't just unilaterally
do" :-) )

> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net