[Toybox] [PATCH] memeater: consume a given amount of memory.

[Rob Landley]

On 1/24/24 15:47, enh via Toybox wrote:
> feel free to push back that "this is too Android-specific"...

It's no sillier than devmem.

You can't malloc more than a long so I'm switching the type to unsigned long and
atolx_range(val, 0, ULONG_MAX).

Should the mlock() be optional? (Maybe -m? Or for backwards compatibility keep
it the default and -M to _not_ lock? Dirtying isn't optional because without
that the malloc just updates a couple pointers and maybe extends a mapping.)

Since this is just dirtying pages do you object to += 4096 in the loop? Or do
you want the ascending numbers over the memory? Or maybe a -f option for fast to
do that and once again leave the default?

Sigh, almost all toybox command line numbers understand unit suffixes. I wince
documenting it here the same as repeatedly explaining "-" in file arguments,
although you know your audience better than I do...

Anyway, quick stab at what cleaning it up might look like attached...

> it's possible that
> a better answer to the Android Go folks' "i wish we always had this on the
> device" is to just always build it for the device as-is (or if we really want to
> hide it away, just bung it in the ghost of toolbox).

I keep meaning to re-examine the ghost of toolbox, but all I actually remember
is a couple christmases back I wrote the first half of a mkvfat and then went
down the rathole of "you don't get to NOT support 12 bit fat, and the cutoff for
switching over is NOT DOCUMENTED, and then 32 bit fat is just weird, and while
I'm here I should look into mtools, and wouldn't it be nice to somehow
genericize that the way zless and zgrep and zdiff work..."

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memeater.c
Type: text/x-csrc
Size: 854 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240125/f4d80c4a/attachment.c>