wireguard-openbsd/sys/kern/dma_alloc.c, branch jd/queueboosts

all pools have their ipl set via pool_setipl, so fold it into pool_init.

2016-09-15T02:00:16Z

the ioff argument to pool_init() is unused and has been for many years, so this replaces it with an ipl argument. because the ipl will be set on init we no longer need pool_setipl. most of these changes have been done with coccinelle using the spatch below. cocci sucks at formatting code though, so i fixed that by hand. the manpage and subr_pool.c bits i did myself. ok tedu@ jmatthew@ @ipl@ expression pp; expression ipl; expression s, a, o, f, m, p; @@ -pool_init(pp, s, a, o, f, m, p); -pool_setipl(pp, ipl); +pool_init(pp, s, a, ipl, f, m, p);

decouple struct uvmexp into a new file, so that uvm_extern.h and sysctl.h

2014-07-08T17:19:21Z

don't need to be married. ok guenther miod beck jsing kettenis

Fix a few format string bugs with -DDEBUG

2014-06-15T11:43:24Z

Reduce uvm include madness. Use instead of

2014-03-28T17:57:11Z

if possible and remove double inclusions. ok beck@, mlarkin@, deraadt@

Make mbufs and dma_alloc be contig allocations.

2011-06-23T21:42:05Z

Requested by dlg@ ok oga@

Put back the change of pool and malloc into the new km_alloc(9) api.

2011-04-18T19:23:46Z

The problems during the hackathon were not caused by this (most likely). prodded by deraadt@ and beck@

Backout the uvm_km_getpage -> km_alloc conversion. Weird things are happening

2011-04-06T15:52:13Z

and we aren't sure what's causing them. shouted oks by many before I even built a kernel with the diff.

- Change pool constraints to use kmem_pa_mode instead of uvm_constraint_range

2011-04-05T01:28:05Z

- Use km_alloc for all backend allocations in pools. - Use km_alloc for the emergmency kentry allocations in uvm_mapent_alloc - Garbage collect uvm_km_getpage, uvm_km_getpage_pla and uvm_km_putpage ariane@ ok

The dma pools need to be IPL_VM

2011-04-02T17:06:21Z

ok dlg

make more dma pools -- all the way up to 64K. at least the scsi

2011-03-17T20:54:17Z

SCIOCCOMMAND wants a dma'able object that big. should we handle this another way, by handling that data in a buf? ok krw