enh-google
enh-google
summary after talking to the boringssl folks: the highest priority thing is AES-GCM acceleration. specifically, using whatever riscv's AES and carry less or polynomial multiply acceleration is. looks like that's...
yeah, i don't think the profiles are particularly relevant to us _except_ insofar as what we can mandate will of course be constrained by the reality of what's actually available...
> That said, the profiles development process has been very drawn out - I don't know if it's because the timing was wrong before, or if there are difficulties that...
> If you can strong-arm folks into one of them then vector is probably the way to go, with the big risk being that other platforms have had performance issues...
boringssl deleted the RC4_INT cruft and just hard-coded `uint32_t`: ``` void RC4(RC4_KEY *key, size_t len, const uint8_t *in, uint8_t *out) { uint32_t x = key->x; ``` my assumption would be...
> Do we need to refine the hwprobe interface to have fast vector misaligned vs fast scalar misaligned? "you add it, i'll call it in Android's CTS tests" :-)
> Will it be a good idea to add repro tests from [llvm/llvm-project#88029](https://github.com/llvm/llvm-project/issues/88029), https://godbolt.org/z/ETaKqTTPc in CTS? yes, i think so. i'd definitely +2 that. feel free to stick it in...
yeah: ``` // Close the file descriptor directly to force filebuf::close to fail. assert(close(fd) == 0); // Ensure that filebuf::close handles the failure. assert(f.close() == nullptr); ``` that's not cool....
> I thought fdsan was older than that, but maybe 30/31 is when it first became enforcing rather than a warning? yeah, you're right. https://android-review.googlesource.com/c/platform/bionic/+/1917499/ improves the docs to make...