Re: kmem API to allocate arrays

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Sun, 30 Jul 2017 16:24:07 +0200
> From: Kamil Rytarowski <n54%gmx.com@localhost>
> 
> I would allow size to be 0, like with the original reallocarr(3). It
> might be less pretty, but more compatible with the original model and
> less vulnerable to accidental panics for no good reason.

Hard to imagine a legitimate use case for size = 0.  Almost always,
the parameter will be sizeof(struct foo), or some kind of blocksize
which necessarily has to be nonzero.

I started writing some example code, and I'm not too keen on having to
write kmem_reallocarr for initial allocation and final freeing, so if
we adopted this, I'd like to have

int	kmem_allocarr(void *ptrp, size_t size, size_t count, km_flag_t flags);
int	kmem_reallocarr(void *ptrp, size_t size, size_t ocnt, size_t ncnt,
	    km_flag_t flags);
void	kmem_freearr(void *ptrp, size_t size, size_t count);

...at which point it's actually not clear to me that we have much of a
use for kmem_reallocarr.  Maybe we do -- I haven't surveyed many
users.

This still doesn't address the question of whether or how we should
express bounds on the allowed sizes of the arrays.