Slow wsmouse down in console

Hi, I hope I'm not the only one being annoyed by the fast movement of wsmouse when in text mode, and this one can be useful. Here is a patch that slows down the cursor by reducing the mouse coordinates proportionally to the console font size. I confess I have only tried it on this laptop with

relayctl(8): add manpage "log" bits

hi, as spotted out by Luis Gustavo on misc@ http://marc.info/?l=openbsd-misc=144859324815165=2 relayct(8) manpage is missing the "log" bits. here is a diff to fix that OKs? // gsoares ? relayctl Index: relayctl.8 === RCS file:

WAPBL: Introducing B_LOCKED buffer flag

Introducing B_LOCKED buffer flag With this flag we can protect buffers that will be used by WAPBL while doing the log of transactions. -- Walter Neto diff --git a/sys/kern/vfs_bio.c b/sys/kern/vfs_bio.c index 63bd7ca..aa0575f 100644 --- a/sys/kern/vfs_bio.c +++ b/sys/kern/vfs_bio.c @@ -743,6

[patch] detect iphone 6 as ugen(4)

Hello, A small diff to detect the iphone 6 as ugen(4) instead of uaudio(4) . -- Laurent Gualdi Index: uaudio.c === RCS file: /cvs/src/sys/dev/usb/uaudio.c,v retrieving revision 1.112 diff -u -p -r1.112 uaudio.c --- uaudio.c 15 Jun

Re: Move score and log files to $HOME for snake(6)

On Wed, Nov 25, 2015 at 03:22:27PM -0500, Ted Unangst wrote: > Theo Buehler wrote: > > > > If you're not going to maintain a list of high scores of the user, you > > could still simplify snscore() further: The score file will just > > contain the user's score as a short, so you could get the

Safer NULL checking for getenv(3) on canfield(6), cfscores(6) and tetris(6)

Hi, As per tb@ and theo@ advise, on a separate diff for snake(6), getenv(3) should have a safer NULL checking since the env var may exist but its contents may still be null and the application can segfault. Also check for PATH_MAX since it may pass the limits, added this one after seeing tb@ last

Re: Safer NULL checking for getenv(3) on canfield(6), cfscores(6) and tetris(6)

On Thu, Nov 26, 2015 at 09:01:08AM +, Ricardo Mestre wrote: > Hi, > > As per tb@ and theo@ advise, on a separate diff for snake(6), getenv(3) should > have a safer NULL checking since the env var may exist but its contents may > still be null and the application can segfault. Also check for

Re: vmm update

On Wed Nov 25 2015 22:00, Gregor Best wrote: > on amd64 with a snapshot from today, I'm getting (transcribed): > > kernel: page fault trap, code=0 > ddb{1}> trace > vm_writepage() at vm_writepage+0x158 > VOP_IOCTL() at VOP_IOCTL+0x44 > vn_ioctl() at vn_ioctl+0x77 >

WAPBL: Introducing buf_adjcnt()

Introducing buf_adjcnt() from Bitrig. It is needed to notify WAPBL that the buffer has size changes. -- Walter Neto diff --git a/sys/kern/vfs_bio.c b/sys/kern/vfs_bio.c index 9bf9b36..459b4fa 100644 --- a/sys/kern/vfs_bio.c +++ b/sys/kern/vfs_bio.c @@ -1206,6 +1206,14 @@ bcstats_print( }

Re: Safer NULL checking for getenv(3) on canfield(6), cfscores(6) and tetris(6)

Committed with a small tweak: > - printuser(pw, 1); > + name = getlogin(); > + printuser(name); Here, `name' should also be checked with: if (name == NULL || *name == '\0') I didn't see the point of passing `name' as a variable, so I moved the getlogin() call down into printuser().

Re: vmm update

Not sure, but on misc you can search for "vmm uvm_fault in vmware player/workstation when Intel VT/AMD-v not enabled" thread from which it looks like vmm requires extended-page tables virtualization feature. Certainly this is not presented on my T500 so I would guess it's neither on your T400.

pledge spamd-setup(8)

Hello, Fairly simple pledge to spamd-setup(8), it needs "rpath" for reading /etc/services, /etc/mail/spamd.conf through cgetent(3) and also to open the gzfile/txt with the blacklists. "proc exec" for lauching pfctl(8) and ftp(1) externally and "inet dns" in order for ftp(1) to download the lists

Re: Swap random with arcrandom on trek(6)

On 2015-11-25, Ricardo Mestre wrote: > While checking if there was still a score file on trek(6) I found that it was > still using random(), Two years ago I went through all of /usr/games and replaced srandomdev() and random() with arc4random*() family functions. Any

Re: Swap random with arcrandom on trek(6)

On 2015-11-25, Michael McConville wrote: >> -t = random() >> 5; > > * what was the point of the shift-right-by-five in the original code? Those games were originally written with the rand(3) function. The lower bits returned by rand(3) suffered from notoriously poor

Re: WAPBL: Introducing buf_adjcnt()

Sorry guys, my bad. It will not compile, there is a warning. Here is the correct diff. -- Walter Neto diff --git a/sys/kern/vfs_bio.c b/sys/kern/vfs_bio.c index 2ce876a..63bd7ca 100644 --- a/sys/kern/vfs_bio.c +++ b/sys/kern/vfs_bio.c @@ -1206,6 +1206,13 @@ bcstats_print( } #endif +void

Fix csqrt(3)

>From http://en.cppreference.com/w/c/numeric/complex/csqrt : csqrt(conj(z)) == conj(csqrt(z)) Before patch csqrt(-4.0 + -0.0i) = 0.0 + 2.0j but should be csqrt(-4.0 + -0.0i) = 0.0 - 2.0j -- Alexandr Shadchin Index: lib/libm/src/s_csqrt.c

Re: pledge spamd-setup(8)

That's the right start to it. On Thu, Nov 26, 2015 at 7:28 AM, Ricardo Mestre wrote: > Hello, > > Fairly simple pledge to spamd-setup(8), it needs "rpath" for reading > /etc/services, /etc/mail/spamd.conf through cgetent(3) and also to open the > gzfile/txt with the

Re: vmm update

On Thu Nov 26 2015 15:11, Karel Gardas wrote: > Not sure, but on misc you can search for "vmm uvm_fault in vmware > player/workstation when Intel VT/AMD-v not enabled" thread from which > it looks like vmm requires extended-page tables virtualization > feature. Looks like this could indeed be

Re: Move score and log files to $HOME for snake(6)

This makes sense to me and keeps the game usable in principle without needing to do silly things. ok beck@ Related is that reading threaded mail in gmail and seeing "Theo" on them so you open them up is insidious. I think I need to change my name to "Theo" as well... On Thu, Nov 26, 2015

Re: WAPBL: Introducing buf_adjcnt()

and yes this latest one is correct. On Thu, Nov 26, 2015 at 11:01 AM, Bob Beck wrote: > Duhh.. my bad walter. it's early.. as of yet undercaffinated. > > > On Thu, Nov 26, 2015 at 10:58 AM, Walter Neto wrote: >> On Thu, Nov 26, 2015 at 10:30:23AM

Index underflow in lex(1)

This nondeterministically underflows _sf_top_ix, causing a segfault: http://www.sccs.swarthmore.edu/users/16/mmcconv1/dump/crash.l The cleanest way to trigger it is: for i in `jot 1000` do cat crash.l | ./lex -t > /dev/null done A backtrace is below. sf_pop() is the only code

Re: WAPBL: Introducing buf_adjcnt()

On Thu, Nov 26, 2015 at 11:01:58AM -0700, Bob Beck wrote: > Duhh.. my bad walter. it's early.. as of yet undercaffinated. > No problem buddy!! :)

WAPBL: Adding the FFS capability to alloc files contiguously

This diff adds B_CONTIG and B_METAONLY low-level allocation flags, and the code to FFS allocate contiguously files. This will be used to alloc WAPBL log file. -- Walter Neto diff --git a/sys/sys/buf.h b/sys/sys/buf.h index c47f3f9..fd38c28 100644 --- a/sys/sys/buf.h +++ b/sys/sys/buf.h @@

lex(1) allocation cleanup

The second reallocarray is unnecessary, but it'll prevent the next forty auditors from being distracted by malloc(x * sizeof(y)). I'm happy to leave malloc if people prefer that. ok? Index: scanflags.c === RCS file:

Re: lex(1) allocation cleanup

We need to make a decision if lex is upstream code or our own fork. If it is not our own fork -- then stay away from this. It is pointless putting increasing delta into code which does not run in risk environments. > The second reallocarray is unnecessary, but it'll prevent the next forty >

Re: lex(1) allocation cleanup

Theo de Raadt wrote: > We need to make a decision if lex is upstream code or our own fork. > > If it is not our own fork -- then stay away from this. It is > pointless putting increasing delta into code which does not run in > risk environments. I thought we had already made that decision based

Re: lex(1) allocation cleanup

> > If it is not our own fork -- then stay away from this. It is > > pointless putting increasing delta into code which does not run in > > risk environments. > > I thought we had already made that decision based on tedu's recent > commits. Not sure though. I am not so sure. That fixed

Re: lex(1) allocation cleanup

Theo de Raadt wrote: > > > If it is not our own fork -- then stay away from this. It is > > > pointless putting increasing delta into code which does not run in > > > risk environments. > > > > I thought we had already made that decision based on tedu's recent > > commits. Not sure though. > >