On 21/04/2021 15:54, Jan Beulich wrote: > In the long run I think we want to do away with these type-unsafe > interfaces, the more that they also request (typically) excess > alignment. This series of entirely independent patches is > eliminating the instances where it's relatively clear that they're > not just "blob" allocations. > > v2 only has commit messages extended. > > 1: x86/MCE: avoid effectively open-coding xmalloc_array() > 2: x86/HVM: avoid effectively open-coding xmalloc_array() > 3: x86/oprofile: avoid effectively open-coding xmalloc_array() > 4: x86/IRQ: avoid over-alignment in alloc_pirq_struct() > 5: EFI/runtime: avoid effectively open-coding xmalloc_array() > 6: kexec: avoid effectively open-coding xzalloc_flex_struct() > 7: video/lfb: avoid effectively open-coding xzalloc_array() > 8: Arm/optee: don't open-code xzalloc_flex_struct()
I'm tempted to nack this, but for now will go with a firm -2 to the whole series. It is unreasonable, at an API level, for *lloc_bytes(...) to not be interchangeable *alloc_array(char, ...), and the former is the clearer way of writing code. The alignment details are internal properties, dubious at best, and totally unreasonable for maintainer to know or care about as far as the API is concerned. There is also no type safety to be gained by making the transformation. If you want to improve the alignment, fix the allocator and the behind-the-scenes semantics. Don't make every callsite more complicated to follow, and definitely don't introduce perf problems from cacheline sharing in the name of typesafey. ~Andrew
