Re: [PATCH v2 0/8] assorted replacement of x[mz]alloc_bytes()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.04.2021 17:23, Andrew Cooper wrote:
> 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.

So you firmly think x*alloc_bytes() is a good interface to have and to
keep? As said above, I'm of the clear opinion that we should get rid
of it (with what you say in the first sentence of the second from last
paragraph being one of the reasons). The fact that it may be a
shorthand when allocating char[] is really, really minor (and violates
consistency of the code base as a whole).

Also, just to make this explicit, patch 4 really is somewhat different
from the others, and hence would better not fall into a general "I don't
like this and won't look at it" bucket. Granted I'm not sure you'll
flame me for other reasons there ...

Jan