Re: [PATCH] Add IOMMU support for Intel VT-d and AMD-Vi

Ok updated the new changes. On Mon, Oct 05, 2020 at 09:54:02PM +0200, Mark Kettenis wrote: > > Date: Thu, 17 Sep 2020 20:54:51 -0500 > > From: Jordan Hargrave > > Cc: ma...@peereboom.org, kette...@openbsd.org, tech@openbsd.org, > > d...@openbsd.org, j...@openbsd.org > > Content-Type: text

[PATCH] Fix a bug where GDB could not display symbols

I refferd to the core of static linked in GDB. However, the backtrace command did not display the symbols correctly. $ cat main.c #include void sub2(int argc, char *argv[]) { int i; for (int i = 0; i <= argc; i++) argv[i][0] = '\0'; } void sub1(int argc, char *a

Re: timeout(9): add clock-based timeouts (attempt 2)

Hi. I'm looking forward to this patch is committed. Because this patch solves my problem about CARP timeout. IIJ, a company that I am working for, is using carp(4) on VMware ESXi hosts for VPN and web gateway services. One is master and the other is backup of carp(4). Active host sometimes failo

diff: refactor MCLGETI() macro

Hi, The name of the macro MCLGETI obsolete. It was made to use a network interface pointer inside. But, now it is just used to define a special length and the interface pointer is discarded. Thus, the following diff renames the macro to MCLGETL and removes the dead parameter ifp. OK? Bye, Jan

Re: setitimer(2): ITIMER_REAL: simplify realitexpire()

> On Oct 7, 2020, at 15:51, Klemens Nanni wrote: > > On Wed, Oct 07, 2020 at 03:34:36PM -0500, Scott Cheloha wrote: >> kn@ wanted to clean it up a while ago but I wan't far enough along >> with hi-res timeouts to change the code yet. > That was not me. I am thinking of this: https://marc.info/

Re: setitimer(2): ITIMER_REAL: simplify realitexpire()

On Wed, Oct 07, 2020 at 03:34:36PM -0500, Scott Cheloha wrote: > kn@ wanted to clean it up a while ago but I wan't far enough along > with hi-res timeouts to change the code yet. That was not me.

setitimer(2): ITIMER_REAL: simplify realitexpire()

Hi, The code in realitexpire(), the ITIMER_REAL timeout callback, is needlessly complicated. kn@ wanted to clean it up a while ago but I wan't far enough along with hi-res timeouts to change the code yet. Hi-res timeouts are now imminent, and setitimer(2) will probably be the first guinnea pig I

diff: remove dead code in a{rm,md}64/a{rm,md}/conf.c

Hi, the cdev_joy_init makro is just used in i386. OK? Bye, Jan Index: amd64/amd64/conf.c === RCS file: /cvs/src/sys/arch/amd64/amd64/conf.c,v retrieving revision 1.71 diff -u -p -r1.71 conf.c --- amd64/amd64/conf.c 6 Jul 2020 04:3

Re: ls: match historic behavior listing empty directories

On Sat, Oct 03, 2020 at 09:21:21AM -0600, Todd C. Miller wrote: > This is adapted from FreeBSD revs 130236 and 130237 which have the > following log message: > > If we are asked to print the total number of blocks, do so even if we > have no entries to print (either due to an empty directo

Re: ls: match historic behavior listing empty directories

Anyone? - todd > This is adapted from FreeBSD revs 130236 and 130237 which have the > following log message: > > If we are asked to print the total number of blocks, do so even if we > have no entries to print (either due to an empty directory or an > error). This makes the -l and -

libexec/security: don't prune mount points

The recent changes to the daily security script will result in it not traversing file systems where the parent mount point is mounted with options nodev,nosuid but the child is mounted with setuid enabled. For example, if /var/www is a separate file system that allows setuid but /var is mounted wi

Re: amap: KASSERT()s and local variables

On 01/10/20(Thu) 14:18, Martin Pieuchot wrote: > Use more KASSERT()s instead of the "if (x) panic()" idiom for sanity > checks and add a couple of local variables to reduce the difference > with NetBSD and help for upcoming locking. deraadt@ mentioned that KASSERT()s are not effective in RAMDISK k

kqueue_scan() refactoring

The diff below has already been presented in August [0]. It is the first step at splitting the kqueue refactoring required for the poll and select rewrite. This first iteration introduces the new API with only minimal changes. The only change in behavior is that the markers' `kn_filter' and `kn_s

Re: diff: remove dead code in a{rm,md}64/a{rm,md}/conf.c

> Date: Wed, 7 Oct 2020 15:14:32 +0200 > From: Jan Klemkow > > Hi, > > the cdev_joy_init makro is just used in i386. > > OK? ok kettenis@ > Index: amd64/amd64/conf.c > === > RCS file: /cvs/src/sys/arch/amd64/amd64/conf.c,v > retr

uvm/uvm_map.h header cleanup

Now that all architectures have been fixed, it's time to remove this... ok? Index: uvm/uvm_map.h === RCS file: /cvs/src/sys/uvm/uvm_map.h,v retrieving revision 1.67 diff -u -p -r1.67 uvm_map.h --- uvm/uvm_map.h 18 Dec 2019 13:3

Re: ifconfig: consistent display of P2P link

On Wed, Oct 07, 2020 at 01:01:29PM +0200, Claudio Jeker wrote: > On Wed, Oct 07, 2020 at 12:27:04PM +0200, Denis Fondras wrote: > > All tunnels & point-to-point addresses are separated by "->" but inet. > > > > Before : > > gre0: flags=8051 mtu 1476 > > index 6 priority 0 llprio 6 > >

Re: ifconfig: consistent display of P2P link

On Wed, Oct 07, 2020 at 12:27:04PM +0200, Denis Fondras wrote: > All tunnels & point-to-point addresses are separated by "->" but inet. > > Before : > gre0: flags=8051 mtu 1476 > index 6 priority 0 llprio 6 > encap: vnetid none txprio payload rxprio packet > groups: gre >

ifconfig: consistent display of P2P link

All tunnels & point-to-point addresses are separated by "->" but inet. Before : gre0: flags=8051 mtu 1476 index 6 priority 0 llprio 6 encap: vnetid none txprio payload rxprio packet groups: gre tunnel: inet 192.0.2.1 -> 198.51.100.1 ttl 64 nodf ecn inet 172.