Re: pool allocator names

2015-08-31 Thread Ted Unangst
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 > > >

Re: pool allocator names

2015-08-30 Thread Mark Kettenis
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

pool allocator names

2015-08-29 Thread Mark Kettenis
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

Re: pool allocator names

2015-08-29 Thread Theo de Raadt
* 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

Re: pool allocator names

2015-08-29 Thread Ted Unangst
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

Re: pool allocator names

2015-08-29 Thread Mark Kettenis
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