Re: Allow top(1) to search arguments

On Fri, Feb 12, 2016 at 06:59:02PM +, Edd Barrett wrote: > Updated diff: I've now tested the updated diff on sparc64 and amd64 with S malloc flags for a while. No issues. Would anyone go as far as "OK"? -- Best Regards Edd Barrett http://www.theunixzoo.co.uk

Re: head(1) -c

Daniel Dickman writes: > On Wed, Mar 9, 2016 at 9:35 PM, Michael McConville wrote: >> Jeremie Courreges-Anglas wrote: >>> >> @@ -66,13 +66,18 @@ main(int argc, char *argv[]) >>> >>argv++; >>> >>} >>> >> >>> >> - while ((ch = getopt(argc,

Re: Xorg stipple

On 10/03/16(Thu) 01:04, Mark Kettenis wrote: > > Date: Wed, 9 Mar 2016 17:09:13 -0600 > > From: joshua stein > > > > Is anyone seriously finding video/Xorg bugs through the default X > > stipple pattern anymore? Xorg changed the default to draw a black > > background a while

Re: bufcache KNF

no. youre giving me random conflicts. unless you have a reason beyond turdshining now is not good time to do that On Thursday, 10 March 2016, Martin Pieuchot wrote: > ok? > > Index: vfs_bio.c > === > RCS file:

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

Stuart Henderson wrote: > On 2016/03/09 20:49, Stefan Kempf wrote: > > Here's a diff that allocates the most commonly used amap slot sizes > > (between 1 and 16) using pool_get(9) instead of malloc(9). That should > > reduce the pressure on kernel virtual address space somewhat (on amd64 > > at

bufcache KNF

ok? Index: vfs_bio.c === RCS file: /cvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.173 diff -u -p -r1.173 vfs_bio.c --- vfs_bio.c 10 Mar 2016 03:09:45 - 1.173 +++ vfs_bio.c 10 Mar 2016 07:15:57 - @@ -1292,14

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

Stuart Henderson wrote: > While running some fairly memory-hungry jobs I hit a state where wchan > in top was showing "fltamap" and the machine locked up (couldn't enter > DDB). > > Which must be this: > > /* didn't work? must be out of RAM. sleep. */ > if

rtwn: check for error during attach

rtwn_attach() may fail due to "unsupported test chip". Unlikely to occur in practice, but still... Index: ic/rtwn.c === RCS file: /cvs/src/sys/dev/ic/rtwn.c,v retrieving revision 1.1 diff -u -p -r1.1 rtwn.c --- ic/rtwn.c 9 Mar 2016

head(1) -c

Today someone bumped into a port that contained head -c calls. While upstream could be prodded to care a bit more about portability, support for head -c is widespread (GNU coreutils, busybox, FreeBSD, NetBSD) so I don't see any value in being different. Plus, tail(1) already has support for -c.

remove useless "abstractions" from urtwn(4)

These function pointers don't provide any benefit. They will just get in the way when we merge this driver with rtwn(4). Tested with: MAC/BB RTL8188CUS, RF 6052 1T1R MAC/BB RTL8188EU, RF 6052 1T1R (URTWN_CHIP_88E) MAC/BB RTL8192CU, RF 6052 2T2R Index: if_urtwn.c

Re: Xorg stipple

On Wed, 9 Mar 2016, joshua stein wrote: > Is anyone seriously finding video/Xorg bugs through the default X > stipple pattern anymore? Xorg changed the default to draw a black > background a while ago (with stipple enabled using the -retro flag), > but we have this local change that reverted it

Re: head(1) -c

Theo de Raadt writes: >> >> I don't see any value in being different. Plus, tail(1) already has >> >> support for -c. >> >> >> >> Comments/ok? >> > >> > Makes sense and works for me. I'll leave a few comments inline. Also: >> > >> >> PS: the next diff will remove

Re: head(1) -c

On Wed, Mar 9, 2016 at 9:35 PM, Michael McConville wrote: > Jeremie Courreges-Anglas wrote: >> >> @@ -66,13 +66,18 @@ main(int argc, char *argv[]) >> >>argv++; >> >>} >> >> >> >> - while ((ch = getopt(argc, argv, "n:")) != -1) { >> >> + while ((ch =

Re: update comment about p_usrpri

On 09:42:32, 9.03.16, Michal Mazurek wrote: > On 22:47:08, 8.03.16, Martin Pieuchot wrote: > > On 08/03/16(Tue) 10:01, Michal Mazurek wrote: > > > p_cpu exists, but p_usrpri isn't based on it. > > > > Michal I lost track of all your comment fixes. One of the accepted > > rules when we read

Re: Xorg stipple

> Date: Wed, 9 Mar 2016 17:09:13 -0600 > From: joshua stein > > Is anyone seriously finding video/Xorg bugs through the default X > stipple pattern anymore? Xorg changed the default to draw a black > background a while ago (with stipple enabled using the -retro flag), > but we

Re: Xorg stipple

> > Is anyone seriously finding video/Xorg bugs through the default X > > stipple pattern anymore? Xorg changed the default to draw a black > > background a while ago (with stipple enabled using the -retro flag), > > but we have this local change that reverted it while adding a silly > > -retard

Re: head(1) -c

Jeremie Courreges-Anglas wrote: > Today someone bumped into a port that contained head -c calls. While > upstream could be prodded to care a bit more about portability, support > for head -c is widespread (GNU coreutils, busybox, FreeBSD, NetBSD) so > I don't see any value in being different.

Re: Xorg stipple

Theo de Raadt wrote: > > > Is anyone seriously finding video/Xorg bugs through the default X > > > stipple pattern anymore? Xorg changed the default to draw a black > > > background a while ago (with stipple enabled using the -retro flag), > > > but we have this local change that reverted it

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

On 2016/03/09 20:49, Stefan Kempf wrote: > Here's a diff that allocates the most commonly used amap slot sizes > (between 1 and 16) using pool_get(9) instead of malloc(9). That should > reduce the pressure on kernel virtual address space somewhat (on amd64 > at least), Thanks for the useful

Re: head(1) -c

Michael McConville writes: > Jeremie Courreges-Anglas wrote: >> Today someone bumped into a port that contained head -c calls. While >> upstream could be prodded to care a bit more about portability, support >> for head -c is widespread (GNU coreutils, busybox, FreeBSD,

Re: head(1) -c

> >> I don't see any value in being different. Plus, tail(1) already has > >> support for -c. > >> > >> Comments/ok? > > > > Makes sense and works for me. I'll leave a few comments inline. Also: > > > >> PS: the next diff will remove documentation for the obsolete "-count" > >> syntax. > > > >

Re: head(1) -c

Jeremie Courreges-Anglas wrote: > >> @@ -66,13 +66,18 @@ main(int argc, char *argv[]) > >>argv++; > >>} > >> > >> - while ((ch = getopt(argc, argv, "n:")) != -1) { > >> + while ((ch = getopt(argc, argv, "c:n:")) != -1) { > >>switch (ch) { > >> + case 'c': >

Re: Xorg stipple

On Wed, Mar 09, 2016 at 05:09:13PM -0600, joshua stein wrote: > Is anyone seriously finding video/Xorg bugs through the default X > stipple pattern anymore? Xorg changed the default to draw a black > background a while ago (with stipple enabled using the -retro flag), > but we have this local

Simplify tcpdump

I think we can assume that people have abs(3) these days... This macro only had one usage, which is visible in the diff. It doesn't look like replacing it should cause any functional changes to the arithmetic. ok? Index: print-icmp6.c

Re: update comment about p_usrpri

On 22:47:08, 8.03.16, Martin Pieuchot wrote: > On 08/03/16(Tue) 10:01, Michal Mazurek wrote: > > p_cpu exists, but p_usrpri isn't based on it. > > Michal I lost track of all your comment fixes. One of the accepted > rules when we read code is that comments are always lying. So I doubt > anyone

Re: arm: dmamap_destroy: remove explicit unload of map

> On 6 Mar 2016, at 9:53 PM, Tobias Ulmer wrote: > > map is passed straight into free where it gets overwritten with junk. > No other arch makes map invalid before free, and my N2100 didn't > suddenly misbehave either. > > ok? ok > > Index: arch/arm/arm/bus_dma.c >

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

Hi, 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, but that will change one day. Lightly tested by

Re: mpsafe vlan(4)

On 09/03/16(Wed) 16:26, David Gwynne wrote: > this is an unfortunately large reworking of vlan(4) to make tx mpsafe This is great but unfortunately hard to review. > it also includes the following: > > - moving away from the vlan specific SIOC[SG]ETVLAN ioctls to the >

Re: NULL checks of static arrays

On 08/03/16(Tue) 14:05, Michael McConville wrote: > Martin Pieuchot wrote: > > On 06/03/16(Sun) 19:20, Michael McConville wrote: > > > We check static arrays against NULL pretty often in the kernel. I > > > suspect most of these are due to recent kernel API changes. Should they > > > be removed,

Re: arm: purge arm8 - and maybe more?

On Wed, Mar 09, 2016 at 01:28:55PM +1100, Jonathan Gray wrote: > On Tue, Mar 08, 2016 at 10:59:42PM +0100, Patrick Wildt wrote: > > Hi, > > > > I'd like to get some opinions on this. ARM8 has probably never ever > > been used with OpenBSD, and I doubt it will ever be. I think it also > > makes