enh-google

Isn't that another argument for hoisting this into the driver? To avoid this being hard-coded in even more build systems than it already is? On Fri, May 15, 2020, 11:02...

> but in the ideal case where an app has only a single shared library ... there may be few enough relocations for the packing to be a net negative?...

> Chrome has an abnormal number of relocations, aiui. exactly. and they might be bloated, but they're not idiots, so my assumption is that your "isn't necessarily better" argument is...

no, no current plans to implement robust mutexes. there is an NDK binder API available from 29 on.

> Thanks for the clarification. while i'm here, let me give a more detailed brain dump. this probably isn't useful to many, but you might be the rare exception... historically...

interesting... is that in addition to HWCAPs for the common stuff like "V", or is the syscall meant to be the only option? otherwise i imagine -- mentally extending the...

the kernel does seem to have admitted defeat here, with this in the 6.3 kernel's uapi header: ``` /*  * Provides information on the availiable set of ISA extensions to...

i still don't get how this isn't _strictly worse_ than just having hwcap/hwcap2/hwcap3 etc? for me on the userspace side i don't feel like this solves any of my problems....

yeah, i meant all the uses of cpuid _apart_ from that one :-)

> It's a vDSO libcall at best does anyone have a link to that? i get how getpid() or whatever works, but i'm struggling a bit to see how _this_...