[Toybox] [PATCH] macOS: target 10.15.

[Rob Landley]

On 6/2/22 19:41, enh wrote:
> Oh, yeah, I think *especially* for macOS where pretty much everyone is always on
> the latest version anyway, unless your Mac equivalent of the seven year rule is
> "support the oldest macOS release that still gets security backports", there's
> no reason to do this. It's pretty rare they add anything significant anyway. 

If you think the mac AOSP prebuilts should require the latest macos version to
run, that's your call. I don't really have a MacOS policy because I'm not
familiar enough with MacOS: they actively exclude any developer who doesn't pay
to play. (And sadly Darwin died in 2006, although I'll blog about that rather
than blathering here.)

The three macos use cases I have at the moment are "test on github", "ship AOSP
prebuilt", and "random mac developer wants to use toybox", which all have
slightly different requirements.

There was a tentative fourth use case: back before Apple switched from bash to
zsh I thought they might eventually show an interest in a finished toysh, but
they did bash->zsh the same way Ubuntu went bash->dash and Canonical showed a
surprisingly adamant refusal to ever admit a mistake. So my previous "might"
went from ~20% chance to like 5% tops. (And their "we don't understand what
vfork was for" move abandons the embedded space too.)

Rob

P.S. The nommu stuff is about realtime response with long battery life: digital
wristwatches could run for 5 years off the same battery because the chip inside
was clocked at something like 32khz, not megahertz let along gigahertz. Sure die
size shrinks help power/performance ratio but it's not linear (transistor
leakage current etc get _worse_ at nanoscale), plus a 5nm chip produces
microwatt signals that need a 45nm interface chip to translate them so it can
talk to the outside world (and not get destroyed by the power surge when
somebody opens the door and moves the air in the room), and for actual direct
I/O (sensors doing analog/digital conversion or driving a small motor) you often
want more like a 250 nanometer chip. So the "die shrinks will solve all this for
us"... isn't true. Plus a 250 nanometer mask is what, $15k? The kind of thing
you can amortize over a 30k unit production run no problem. A 5 nanometer mask
isn't gonna cost less than $10 million any time soon, you've gotta make a LOT of
the same chip for that to make economic sense. (The sky130 fab Google partnered
with is actually a bit exotic, that's a "mixed signal" process doing a different
resolution on each layer of the design, which makes routing extra-fun. Jeff
Dionne is trying to do a j-core chip through that which can track GPS signals in
a battery powered device, but it turns out their toolchain doesn't actually work
and the first couple rounds of chips that went through the fab were all duds. He
thinks he's fixed up most of it...)

P.P.S. Here's a 2015 presentation about running nommu Linux on a chip with 256k
of SRAM and no DRAM.
https://elinux.org/images/9/90/Linux_for_Microcontrollers-_From_Marginal_to_Mainstream.pdf
It's a pity the Linux Foundation accidentally deleted that year's ELC videos off
of youtube, his talk was nice too. Anyway, the trick is trimming kernel data
structures, XIP ROMFS so your binaries only need their .data and .bss segments
in RAM, and nommu not wasting memory on page tables. No DRAM means no DRAM
controller spending power on refresh cycles...