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 top(1
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 clock_gettime(3)
CLOC
> 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 to
> use in top(1), w(1),
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 ke
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 factor.
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 r
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
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 di
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 @@ sta
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
...
ok
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 f
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 acce
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 historic
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 cod
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
>>> (GNU/Darwin/FreeBSD/Sm
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 FROM
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) 19:09, Florian Riehm wrote:
Hi,
This
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 co
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 iwn(
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
==
+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 the recent
>> diffs for libutil and libkvm
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 usi
> 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, Florian Riehm wrote:
> > > > Hi,
> >
> 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 wrote:
> >> On Tue, Dec 12 2017, Seb
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 would like confirmation because for al
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:
:> > > Hi,
:> > >
> 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 used
> symbol visibil
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 'boot reset'.
> > >
> 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.
> >
> > Tested on
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 f
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 kee
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 hidden. However, while
>
> 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 static or at least hid
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
anothe
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
35 matches
Mail list logo
