Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Sat, 29 Aug 2015 18:38:45 -0400
> >
> > Mark Kettenis wrote:
> > > This diff is purely mechanical. This means that it also changes some
> > > pool_allocator_nointr into pool_allocator_single where the intention
> > >
From: Ted Unangst t...@tedunangst.com
Date: Sat, 29 Aug 2015 18:38:45 -0400
Mark Kettenis wrote:
This diff is purely mechanical. This means that it also changes some
pool_allocator_nointr into pool_allocator_single where the intention
was to signal that the pool would never be used in
So whe have this default pool allocator called
pool_allocator_nointr, which is perfectly safe to be used in
interrupt context. That always confuses the hell out of me. So here
is a diff that gives the allocators more sensible names. With this
change we have:
* pool_allocator_single: A single
* pool_allocator_multi_ni: A multi page allocator that is *not* safe
for use in interrupts. Also less efficient than
pool_allocator_single. It allocates kva from kernel_map, which is
significantly more plentyful.
We are the knights who say non-interruptable. Honestly, ni feels
a
Mark Kettenis wrote:
This diff is purely mechanical. This means that it also changes some
pool_allocator_nointr into pool_allocator_single where the intention
was to signal that the pool would never be used in interrupt context.
However, using pool_allocator_single in those cases isn't a big
From: Theo de Raadt dera...@cvs.openbsd.org
Date: Sat, 29 Aug 2015 16:19:25 -0600
* pool_allocator_multi_ni: A multi page allocator that is *not* safe
for use in interrupts. Also less efficient than
pool_allocator_single. It allocates kva from kernel_map, which is