[Toybox] sizeof(toybuf)

[Rob Landley]

On 4/14/23 18:49, enh wrote:
>     > i don't like assert(), but **static_assert** is really useful for things like
>     > this where you want to say "this code makes an assumption that you can test at
>     > compile time".
> 
>     Compile time is the time to care about that sort of thing, yes.
> 
>     Kinda wonder about portability on weirdness like qnx (or the guy in email who's
>     asking about uclibc-ng). I suspect any such asserts would be a CFG_DEBUG option
>     maybe in portability.c? Hmmm...
> 
> they haven't made other complaints about C11, so presumably static_assert is
> fine too?

I'm not worried about it erroring, I'm worried about it potentially triggering
in who knows what linker environment possibly producing mach-o binaries.

>     >     B) it was only ever coincidentally page size, and huge pages are a
>     thing even on
>     >     x86.
>     >
>     >
>     > well, huge pages are different from non-4KiB non-huge pages.
> 
>     There was a lot of talk a while back about getting the kernel to dynamically use
>     them (false starts when I was reading about it), but I don't follow lwn.net
>     <http://lwn.net> or
>     lkml nearly as closely in 2023 as I did in 2018. It just got too unpleasant even
>     to check over the weekly web archive...
> 
> _transparent_ huge pages is yet another different thing :-)

I am in favor of not having to care, but they did seem to be having a hard time
with it.

>     Hmmm... Does it actually help to page align them, do you think? Not sure how to
>     benchmark that...
> 
> (i was half expecting it to be page aligned for free, as the
> joint-second-largest OBJECT in toybox, but readelf says it isn't, and neither is
> `this`.)
> 
> i don't have good benchmarks either, or i'd have given you data. the build team
> does keep track of where all the time goes in builds, but (other than that
> pathological case we had in sed) toybox is unlikely to make their hit list.

Yeah, but a zillion little ones add up. Not sure _what_ helped in your earlier
thingy, and am now curious...

(And I have NO idea what state I've gotten thunderbird into where the cursor
blinks once an then vanishes until I move it again. And on more than one
occasion when I hit enter has inserted a line BELOW the last place typing
happened...)

> (i think for ps, the interesting question is "why does toybox top take 10%
> cpu?". and although i don't know the answer to that, i don't think that's
> toybuf's fault :-) )

I think last time I looked at it I was squinting at the unicode fontmetrics
stuff, but I agree it's waaaaay too expensive. On the todo list but nobody else
had piped up saying it was blocking them...

>     Oh, hang on:
> 
>           if (bytes<0 || bytes>(1<<30)) len = (1<<30);
>           // glibc added this constant in git at the end of 2017, shipped 2018-02.
>           // Android's had the constant for years, but you'll get SIGSYS if you use
>           // this system call before Android U (2023's release).
>     #if defined(__NR_copy_file_range) && !defined(__ANDROID__)
>           len = syscall(__NR_copy_file_range, in, 0, out, 0, len, 0);
>     #else
> 
>     That might be worth looking into...
> 
> well, the _build_ performance is all on the host. (though until we switch from
> host glibc to host musl, we probably don't have __NR_copy_file_range defined
> anyway because of our ancient glibc.)

Given my recent migration from slack to discord because debian oldstale won't
update, I can't throw stones...

> as for the device, we're caught between caring about the current OS version and
> wanting the static binary to be able to run on old OS versions. we can trivially
> remove this, but it will break any calling code for pre-U (which is literally
> "everything currently in anyone's hands"). right now we don't have any known
> users of the _device_ toybox static prebuilt, but changing this would likely
> preclude that.

Sigh. I tried to make it gracefully fall back, and you guys are sending kill
signals to anything that uses a system call you don't recognize.

Need a posix container...

> if we want to go this route, we'll probably have to go with something like a
> signal handler for SIGSYS and a boolean. or a weak declaration of the
> copy_file_range() *function*? no, because that's useless for the static linking
> we're concerned about.
> 
> oh, wait... we should just be able to use android_get_device_api_level()...
> 
> i think something like this should work?

Sigh, lemme finish and check in the fs_type_name() redo. (So many dirty files in
my tree. Closing tabs...)

Rob