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
> > > was to signal that the p
> 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
> > was to signal that the pool would never be used in interrup
> From: Theo de Raadt
> 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
> significantly more plentyful
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 b
* 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 b
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 singl
