remove 'returns no value' from man pages

2016-03-11 Thread Michael McConville
This is specified only irregularly, and people who don't know what a void return type means are beyond help anyway. This also adds a sentence specifying that X509_free(3) is NULL-safe, now that we've removed all NULL-checks for it. I should sweep through and add the sentence the rest of the

Re: hang with processes in fltamap: how can I identify running out of RAM?

2016-03-11 Thread Stuart Henderson
On 2016/03/10 19:18, Stefan Kempf wrote: > There's still at least one issue with the diff. Again in amap_extend(). > The slotalloc computation was still off :-( It's not perfect but this is very significantly better. I've put it under load and the machine is still ok. Here's a snapshot of a top

Re: scheduler: abstract away spc_whichqs

2016-03-11 Thread Michael McConville
Michal Mazurek wrote: > spc_whichqs is an implementation specific variable of the bsd scheduler. > Abstract it away, easing potential future rewrite. > > This gets rid of curcpu_is_idle() that's used only once, and replaces it > with a more general cpu_is_idle(curcpu()). > > As far as I can tell

Re: Probable logic error in st(4)

2016-03-11 Thread Miod Vallat
> sys/scsi/st.c:1024 uses: > >> cmd->len != 0 > > as a condition. However, cmd is of type struct scsi_rw_tape, and its len > field is of type u_int8_t len[3]. Therefore, the condition is always > true because len is treated as a pointer. Indeed, this looks like an oversight and should probably

Re: head(1) -c

2016-03-11 Thread Jeremie Courreges-Anglas
Jeremie Courreges-Anglas writes: > Ingo Schwarze writes: > >> Hi, > > Hi Ingo, > >> two general remarks: >> >> 1) The head(1) utility is supposed to handle text files. Our >> manual page doesn't mention that technicality - in general, our >> manuals

scheduler: abstract away spc_whichqs

2016-03-11 Thread Michal Mazurek
spc_whichqs is an implementation specific variable of the bsd scheduler. Abstract it away, easing potential future rewrite. This gets rid of curcpu_is_idle() that's used only once, and replaces it with a more general cpu_is_idle(curcpu()). As far as I can tell no binary change. Index:

Re: malloc: 1st small step in long way to multiple pools

2016-03-11 Thread Otto Moerbeek
On Fri, Mar 11, 2016 at 01:43:09PM +0100, Martin Pieuchot wrote: > On 09/03/16(Wed) 10:06, Otto Moerbeek wrote: > > a future goal for malloc is to use multiple pools in threaded environments, > > to reduce lock contention. > > > > This is a small first step towards that goal: move two globals

rtwn dma init

2016-03-11 Thread Stefan Sperling
The urtwn(4) driver does different things to init dma. So it seems better to move all DMA init code into the bus-specific part of the driver, not just a small part of it. Tested on: MAC/BB RTL8188CE, RF 6052 1T1R Index: ic/rtwn.c

Re: malloc: 1st small step in long way to multiple pools

2016-03-11 Thread Martin Pieuchot
On 09/03/16(Wed) 10:06, Otto Moerbeek wrote: > a future goal for malloc is to use multiple pools in threaded environments, > to reduce lock contention. > > This is a small first step towards that goal: move two globals to the > pool-specific struct dir_info. Currently there's only a single pool,

Re: malloc: 1st small step in long way to multiple pools

2016-03-11 Thread Otto Moerbeek
On Thu, Mar 10, 2016 at 10:31:17PM -0800, Michael McConville wrote: > Otto Moerbeek wrote: > > a future goal for malloc is to use multiple pools in threaded > > environments, to reduce lock contention. > > > > This is a small first step towards that goal: move two globals to the > >