Doing
size = struct_size(ptr, flex_member, count);
ptr = kmalloc(size, gfp);
is basically two fairly straightforward things and easy to understand.
You can *scan* that code, and each piece is simple enough that it
makes intuitive sense.
No, 'struct_size()' isn't exactly a very intuitive thing, but written
that way it's also not very surprising or complicated to parse at a
glance.
In contrast,
ptr = kmalloc_flex_sz(*ptr, flex_member, count, gfp, &size);
does *not* make intuitive sense, I believe. Now you have five
different arguments, and it's actually somewhat hard to parse, and
there are odd semantics.
In contrast, the simple versions that take
ptr = kmalloc(sizeof(*ptr), gfp);
and turn it into
ptr = kmalloc_obj(*ptr, gfp);
actually become *simpler* to read and understand.
Yes, there are some other advantages to the combined version (ie that
whole thing where 'kmalloc_obj()' now returns a proper _type_ - type
safety is always good, and avoiding void pointers is a real thing),
but I do think that the major advantage is "simpler to read".
Because in the end, simple code that does what you intuitively expect
it to do, is good code, and hopefully less buggy.
Linus
what about below interface:
ptr = kmalloc_flex(*ptr, member, count, gfp);
size = kmalloc_flex_get_size(ptr);
so, users that don't care about size would not need to read or store it
but those that need the size (likely to pass the whole struct via some
generic interface) will simply ask for it
note that there are some caveats, like user could add something like
ptr->count++;
to destroy naive implementation for kmalloc_flex_get_size() above,
but we don't need to make knee shooting any less painful
another note, there is ksize(), and if we would like to waste some more
for actual size asked (as opposed to allocated), there could be a proper
function (instead of the macro that will work only when user not messing
with conventions) for kmalloc_flex_get_size()
