Re: clock_gettime: add CLOCK_BOOTTIME clockid

On Thu, Dec 14, 2017 at 06:47:02PM -0600, Scott Cheloha wrote: > Hi, > > Attached is a diff adding a new clockid, CLOCK_BOOTTIME, for use with > clock_gettime(2). The value of CLOCK_BOOTTIME is the time elapsed > since the system booted, i.e. the system uptime. The diff puts it to > use in

Re: clock_gettime: add CLOCK_BOOTTIME clockid

On Thu, Dec 14, 2017 at 6:33 PM, David Gwynne wrote: ... > however, it implies that our CLOCK_MONOTONIC behaviour needs to change. > right now it represents wall time since boot, but it should be time after > boot minus how long it has been suspended? > Nope. To quote

Re: clock_gettime: add CLOCK_BOOTTIME clockid

> On 15 Dec 2017, at 10:47, Scott Cheloha wrote: > > Hi, > > Attached is a diff adding a new clockid, CLOCK_BOOTTIME, for use with > clock_gettime(2). The value of CLOCK_BOOTTIME is the time elapsed > since the system booted, i.e. the system uptime. The diff puts it

clock_gettime: add CLOCK_BOOTTIME clockid

Hi, Attached is a diff adding a new clockid, CLOCK_BOOTTIME, for use with clock_gettime(2). The value of CLOCK_BOOTTIME is the time elapsed since the system booted, i.e. the system uptime. The diff puts it to use in top(1), w(1), and snmpd(8). CLOCK_BOOTTIME originated in Linux in the 2.6.39

Re: Removal of PIM support in kernel

On Sun, 2017-12-10 at 12:48 -0700, Theo de Raadt wrote: > In our tree, all security or front-facing code must be maintained by > an interested individual/group. If it isn't maintained eventually it > will become a hinderance towards other developments, or error prone > and therefore a risk

Re: Removal of PIM support in kernel

On Sun, 2017-12-10 at 19:14 +0100, Martin Pieuchot wrote: > On 10/12/17(Sun) 17:59, Joachim Nilsson wrote: > > [...] > > Now, I've got a few worried questions recently about the removal[3] > > of PIM support in OpenBSD, so I thought I'd ask here. Why have you > > removed it? > [...] > Last year

Re: rpc: use monotime for timeouts

On Thu, 14 Dec 2017 18:00:08 +0100, Jeremie Courreges-Anglas wrote: > Here's another diff on top to remove two useless temporary variables, > and unify the names of the remaining ones. Looks correct, OK millert@ - todd

Re: Symbols.map for libfuse

On Thu, 14 Dec 2017, Jeremie Courreges-Anglas wrote: > > Looks good to me, but I can't judge if you're removing too much, so > > maybe you should wait for an ok from helg@ as well. > > I have completed a partial ports bulk build with all libfuse consumers, > no visible fallout, with the updated

Re: rpc: use monotime for timeouts

Diff committed, thank you Scott. Here's another diff on top to remove two useless temporary variables, and unify the names of the remaining ones. ok? Index: clnt_tcp.c === --- clnt_tcp.c.orig +++ clnt_tcp.c @@ -385,7 +385,7 @@

httpd: send location: header for 307 and 308 status codes

308 and 307 are the new 301 and 302 HTTP Status Codes: https://tools.ietf.org/html/rfc7538 https://tools.ietf.org/html/rfc7231#section-6.4.7 ... The server SHOULD generate a Location header field ([RFC7231], Section 7.1.2) in the response containing a preferred URI reference ...

Re: Add reset option to boot command of ddb(4)

On Thu, Dec 14, 2017 at 02:05:36PM +0100, Martin Pieuchot wrote: > On 14/12/17(Thu) 13:37, Florian Riehm wrote: > > [...] > > If the command could lead to DMA issues, I agree that we should not > > introduce it. > > The problem is not only DMA issues. The problem is that ddb(4) will > never get

C mutex impl. for x86

Diff below moves amd64 and i386 mutex to the common C implementation. The differences are: - membar_enter_after_atomic(9) instead of membar_enter(9), and - membar_exit_before_atomic(9) instead of membar_exit(9) I'd appreciate any performance test to know if the performance degradation is

Re: sign of char on arm64

On Thu, Dec 14, 2017 at 12:17:56PM +0100, Mark Kettenis wrote: > Pretty sure Linux uses the same defaults for the signedness of char as > everybody else. But since both signed and unsigned char have to work, > it might very well be that the rust developers decided to ignore this > largely

Re: Add reset option to boot command of ddb(4)

On 14/12/17(Thu) 13:37, Florian Riehm wrote: > [...] > If the command could lead to DMA issues, I agree that we should not > introduce it. The problem is not only DMA issues. The problem is that ddb(4) will never get fixed. If we give people a 'reset' button then how long until the core dump

Re: w: don't print any header with -h

On 12/14/17 13:56, Jasper Lievisse Adriaanse wrote: > On Thu, Dec 14, 2017 at 01:35:18PM +0100, Martijn van Duren wrote: >> Hello Jasper, >> >> On 12/14/17 13:22, Jasper Lievisse Adriaanse wrote: >>> Hi, >>> >>> currently w(1) on OpenBSD differs from other implementations >>>

Re: w: don't print any header with -h

On Thu, Dec 14, 2017 at 01:35:18PM +0100, Martijn van Duren wrote: > Hello Jasper, > > On 12/14/17 13:22, Jasper Lievisse Adriaanse wrote: > > Hi, > > > > currently w(1) on OpenBSD differs from other implementations > > (GNU/Darwin/FreeBSD/SmartOS) in that 'w -h' does print the > > 'USER TTY

Re: Add reset option to boot command of ddb(4)

On 12/14/17 12:20, Mark Kettenis wrote: Date: Thu, 14 Dec 2017 11:49:18 +0100 From: Martin Pieuchot On 14/12/17(Thu) 11:30, Mark Kettenis wrote: X-Originating-IP: 88.153.7.170 Date: Thu, 14 Dec 2017 10:30:21 +0100 From: Martin Pieuchot On 13/12/17(Wed)

Re: w: don't print any header with -h

Hello Jasper, On 12/14/17 13:22, Jasper Lievisse Adriaanse wrote: > Hi, > > currently w(1) on OpenBSD differs from other implementations > (GNU/Darwin/FreeBSD/SmartOS) in that 'w -h' does print the > 'USER TTY FROM ...' header whereas the others don't. > > Is there a specific reason for it or

Re: background scan for iwn(4)

No regressions noticed using a single AP setup. iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, MIMO 2T2R, MoW On Wed, Dec 13 2017, Stefan Sperling wrote: > Since nobody is reporting problems with iwm(4), I took some time to write the > corresponding diff for

w: don't print any header with -h

Hi, currently w(1) on OpenBSD differs from other implementations (GNU/Darwin/FreeBSD/SmartOS) in that 'w -h' does print the 'USER TTY FROM ...' header whereas the others don't. Is there a specific reason for it or could this diff below go in? Index: w.c

Re: Symbols.map for libfuse

+cc Helg On Thu, Dec 14 2017, Mark Kettenis wrote: >> From: Jeremie Courreges-Anglas >> Date: Thu, 14 Dec 2017 10:40:50 +0100 >> >> When reviewing helg@'s last diff I noticed a bunch of stuff that >> shouldn't be exported. So here's a diff similar to

Re: sign of char on arm64

On Thu, Dec 14, 2017 at 12:17:56PM +0100, Mark Kettenis wrote: > > >> > > >> I would certainly not expect NetBSD and FreeBSD to have "char" signed by > > >> default. afaik the powerpc, arm and arm64 ABIs define "char" as > > >> unsigned. > > >> > > >> FreeBSD documents those architectures as

Re: Add reset option to boot command of ddb(4)

> Date: Thu, 14 Dec 2017 11:49:18 +0100 > From: Martin Pieuchot > > On 14/12/17(Thu) 11:30, Mark Kettenis wrote: > > > X-Originating-IP: 88.153.7.170 > > > Date: Thu, 14 Dec 2017 10:30:21 +0100 > > > From: Martin Pieuchot > > > > > > On 13/12/17(Wed) 19:09,

Re: sign of char on arm64

> From: Jeremie Courreges-Anglas > Date: Thu, 14 Dec 2017 12:06:05 +0100 > > On Wed, Dec 13 2017, Sebastien Marie wrote: > > First, thanks to all people that answered, off-list or not. > > > > On Tue, Dec 12, 2017 at 10:01:14PM +0100, Jeremie Courreges-Anglas

Re: sign of char on arm64

On Wed, Dec 13 2017, Sebastien Marie wrote: > First, thanks to all people that answered, off-list or not. > > On Tue, Dec 12, 2017 at 10:01:14PM +0100, Jeremie Courreges-Anglas wrote: >> On Tue, Dec 12 2017, Sebastien Marie wrote: >> >> [...] >> >> > But I

Re: Add reset option to boot command of ddb(4)

On 2017 Dec 14 (Thu) at 11:49:18 +0100 (+0100), Martin Pieuchot wrote: :On 14/12/17(Thu) 11:30, Mark Kettenis wrote: :> > X-Originating-IP: 88.153.7.170 :> > Date: Thu, 14 Dec 2017 10:30:21 +0100 :> > From: Martin Pieuchot :> > :> > On 13/12/17(Wed) 19:09, Florian Riehm wrote:

Re: Symbols.map for libfuse

> From: Jeremie Courreges-Anglas > Date: Thu, 14 Dec 2017 10:40:50 +0100 > > When reviewing helg@'s last diff I noticed a bunch of stuff that > shouldn't be exported. So here's a diff similar to the recent > diffs for libutil and libkvm. To get the list of public symbols I

Re: Add reset option to boot command of ddb(4)

On 14/12/17(Thu) 11:30, Mark Kettenis wrote: > > X-Originating-IP: 88.153.7.170 > > Date: Thu, 14 Dec 2017 10:30:21 +0100 > > From: Martin Pieuchot > > > > On 13/12/17(Wed) 19:09, Florian Riehm wrote: > > > Hi, > > > > > > This patch follows bluhm's attempt for a ddb command

Re: Add reset option to boot command of ddb(4)

> X-Originating-IP: 88.153.7.170 > Date: Thu, 14 Dec 2017 10:30:21 +0100 > From: Martin Pieuchot > > On 13/12/17(Wed) 19:09, Florian Riehm wrote: > > Hi, > > > > This patch follows bluhm's attempt for a ddb command 'boot reset'. > > My first attempt was not architecture aware.

Symbols.map for libfuse

When reviewing helg@'s last diff I noticed a bunch of stuff that shouldn't be exported. So here's a diff similar to the recent diffs for libutil and libkvm. To get the list of public symbols I used symbol visibility. The diff below only reduces the symbols list, it does not remove PLT entries

Re: Add reset option to boot command of ddb(4)

On 13/12/17(Wed) 19:09, Florian Riehm wrote: > Hi, > > This patch follows bluhm's attempt for a ddb command 'boot reset'. > My first attempt was not architecture aware. > > Tested on i386 by bluhm@ and on amd64 by me. I don't understand why we need to add "boot reset"? To not fix ddb(4) and

Re: Symbols.map for libkvm

On Wed, Dec 13 2017, Philip Guenther wrote: > Inspired by kettenis@'s diff for libutil, here's a diff to do the > (simpler) work for libkvm, > > The symbols this hides are just the linker defined ones; we've already > declared the internal C symbols static or at least

Re: Symbols.map for libkvm

> Date: Wed, 13 Dec 2017 23:05:24 -0800 > From: Philip Guenther > > Inspired by kettenis@'s diff for libutil, here's a diff to do the > (simpler) work for libkvm, > > The symbols this hides are just the linker defined ones; we've already > declared the internal C symbols

Re: Add "-c command" option to script(1)

On Thu, Dec 14, 2017 at 09:23:29AM +0100, Paul de Weerd wrote: > Another use I personally find very convenient is this: > > [weerd@pom] $ script -c "vmctl start test -c" > > Hope others see value here too :) > > Paul > you could add this as an EXAMPLES section, since it nicely describes

Re: Add "-c command" option to script(1)

Another use I personally find very convenient is this: [weerd@pom] $ script -c "vmctl start test -c" Hope others see value here too :) Paul On Thu, Dec 14, 2017 at 08:45:19AM +0100, Paul de Weerd wrote: | Hi Jason, | | Thank you for your quick feedback! I've incorporated yours and | off-list