Re: Vim core dump

On Mon, Nov 19, 2018 at 09:13:51PM +0100, def...@posteo.de wrote: > Hi, all > > Could you be so kind to explain me why OpenBSD has no Dump core issue with > Vim : > https://github.com/vim/vim/issues/3619 > > Many thanks > > Hard question without delving deep and speding lots of time. But in t

wscons: FIOGETOWN

Hi, Now that wscons is using sigio, adding support for FIOSETOWN/TIOCGPGRP is trivial. Also, visa@ pointed out that FIOSETOWN gets translated into TIOCSPGRP by sys_ioctl(), handling of FIOSETOWN is therefore redundant. Comments? OK? Index: wskbd.c

Re: prevent bgpd from starting when control socket already used

On Mon, Nov 19, 2018 at 09:45:55AM +0100, Claudio Jeker wrote: > On Sun, Nov 18, 2018 at 11:40:40PM +0100, Remi Locherer wrote: > > Hi, > > > > from the discussion I understand nobody rejects the functionality. > > > > To ease the review here again the diff (with incorporated feedback from > > an

bpf_mtap_ether() shouldn't recalculate 802.1P priority

vlan(4) set's up the vlan tag with the right prio, so bpf shouldn't have to do it and overwrite it. ok? Index: bpf.c === RCS file: /cvs/src/sys/net/bpf.c,v retrieving revision 1.170 diff -u -p -r1.170 bpf.c --- bpf.c 13 Jul 201

Vim core dump

Hi, all Could you be so kind to explain me why OpenBSD has no Dump core issue with Vim : https://github.com/vim/vim/issues/3619 Many thanks

Re: pvclock(4)

Reyk Floeter(r...@openbsd.org) on 2018.11.19 13:12:46 +0100: > Feedback? Tests? OKs? test on my incarnation of kvm: OpenBSD 6.4-current (GENERIC.MP) #0: Mon Nov 19 18:32:29 CET 2018 ben...@test.openbsd.fluchtwagenfahrer.de:/sys/arch/amd64/compile/GENERIC.MP real mem = 2097004544 (1999MB) avai

fstat(1) multiple -p and -u arguments

So I hacked this together because I got annoyed by the fact that for every pid I want to investigate I had to rerun fstat. Diff below alleviates the searched pid from kvm_getfiles(3) to fstat(1). I left atomicity (is there any in kvm_getfiles?) in place, by retrieving everything in one go and fil

Re: sdmmc(4) support for suspend/resume with eMMC devices

Mark Kettenis wrote: > > 1. How do we know if a device is non-removable, I don't think an MMC > > device indicates this, maybe we have to determine this by the > > controller? > > The hardware really doesn't know. It all depends how the controller > is actually wired up. You have to rely on th

Re: sdmmc(4) support for suspend/resume with eMMC devices

> Date: Sun, 11 Nov 2018 13:10:19 + > From: Ben Pye > > Hey all, > > In my quest for better OpenBSD support on my Chromebook 13 I have found > that sdmmc(4)'s current strategy for suspend/resume only really works > for removable storage. Upon a suspend it marks the device as dying, and > upo

pvclock(4)

Hi, the attached diff is another attempt at implementing a pvclock(4) guest driver. This improves the clock on KVM and replaces the need for using the VM-expensive acpihpet(4). While pvclock(4) is available on KVM, Xen, Hyper-V (in a modified form), it currently only attaches under KVM: pvbus0

Re: prevent bgpd from starting when control socket already used

On Sun, Nov 18, 2018 at 11:40:40PM +0100, Remi Locherer wrote: > Hi, > > from the discussion I understand nobody rejects the functionality. > > To ease the review here again the diff (with incorporated feedback from > anton@ (redundant parens)). > > Any comments or OKs? Not sure about this, sin