Re: check KTRPOINT() before calling ktrpledge()

2016-07-09 Thread Philip Guenther
On Mon, Jun 20, 2016 at 11:34 PM, Michal Mazurek wrote: > Don't ktrace pledge if it is not enabled. Committed...through the real reason to do this is that KTRPOINT() is what guarantees that writing of ktrace records can't loop back into ktrace. Philip Guenther

Re: cat.1 forward refs

2016-07-09 Thread Ted Unangst
Jason McIntyre wrote: > therefore the pattern is currently to say it explicitly. we could > do both, but that adds verbosity. it's a trade off, no? i wouldn;t > be against documenting both bits of information, but i'm not sure > it's really worth it. > > i think it'd be wrong to lose the info

Re: acpiec: handle burst mode failure

2016-07-09 Thread Philip Guenther
On Sat, Jul 9, 2016 at 6:08 AM, joshua stein wrote: > On Fri, 08 Jul 2016 at 22:34:34 -0700, Philip Guenther wrote: >> On Fri, Jul 8, 2016 at 4:51 PM, joshua stein wrote: >> > If the EC fails to go into burst mode for whatever reason, the Burst >> >

Re: smu-pulsar node delays G5 boot

2016-07-09 Thread Marcus Glocker
On Sat, Jul 09, 2016 at 10:24:59PM +0200, Mark Kettenis wrote: > > Date: Sat, 9 Jul 2016 22:07:16 +0200 > > From: Marcus Glocker > > > > On every boot on my G5 the 'smu-pulsar' node hangs for around 66 seconds > > in autoconfs config_search() it seems before the boot process

Re: calendar(1) handling of Weekday+5 and 31st events

2016-07-09 Thread Ted Unangst
Andy Bradford wrote: > And here is the patch: > > Index: calendar/day.c > === > RCS file: /home/cvs/src/usr.bin/calendar/day.c,v > retrieving revision 1.32 > diff -u -p -r1.32 day.c > --- calendar/day.c8 Dec 2015 19:04:50 -

calendar(1) handling of Weekday+5 and 31st events

2016-07-09 Thread Andy Bradford
Hello, The following patch seems to allow calendar to better handle the fifth weekday and 31st events. Currently, both events match also at the beginning of certain months which doesn't seem to make sense. For example, March 02 is considered a 31st this year and July 03

Re: smu-pulsar node delays G5 boot

2016-07-09 Thread Mark Kettenis
> Date: Sat, 9 Jul 2016 22:07:16 +0200 > From: Marcus Glocker > > On every boot on my G5 the 'smu-pulsar' node hangs for around 66 seconds > in autoconfs config_search() it seems before the boot process continues: > > "smu-pulsar" at iic2 addr 0x6a not configured > > I

smu-pulsar node delays G5 boot

2016-07-09 Thread Marcus Glocker
On every boot on my G5 the 'smu-pulsar' node hangs for around 66 seconds in autoconfs config_search() it seems before the boot process continues: "smu-pulsar" at iic2 addr 0x6a not configured I don't know why. Anyone else seeing this with a 'smu-pulsar' node in his FDT? Anything

Re: [armv7] introducing tipru(4)

2016-07-09 Thread Theo de Raadt
I am pretty unhappy about drivers like this arriving in the tree. I just don't see any trustworthy way to use them, and lacking trust -- I don't understand the worth. Givings hugs to trustworthy designs is an OpenBSD agenda. Giving scowls to untrustworthy designs is another OpenBSD agenda.

Re: route6d summer cleanup

2016-07-09 Thread Jeremie Courreges-Anglas
j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: > j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: > >> j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: >> >>> Nobody cares about route6d, and it shows: runas as root, not chrooted. >>> Also it uses wide pledge(2) permissions. >>> >>> I have

Re: Better for mount(2)

2016-07-09 Thread Jason McIntyre
On Sat, Jul 09, 2016 at 06:20:49PM +0300, Vadim Zhukov wrote: > Hello all. > evening. > As found by some of my students, mount(2) lacks description of some > flags used by userland. After trying to sync things out, I realized > that this page is not well organized at all. For example, unmount >

Better for mount(2)

2016-07-09 Thread Vadim Zhukov
Hello all. As found by some of my students, mount(2) lacks description of some flags used by userland. After trying to sync things out, I realized that this page is not well organized at all. For example, unmount syscall is mentioned closer to end, after description of flags that it could use. I

Re: acpiec: handle burst mode failure

2016-07-09 Thread joshua stein
On Fri, 08 Jul 2016 at 22:34:34 -0700, Philip Guenther wrote: > On Fri, Jul 8, 2016 at 4:51 PM, joshua stein wrote: > > If the EC fails to go into burst mode for whatever reason, the Burst > > Acknowledge byte will not be there to read, which means the status > > won't have

Re: [armv7] introducing tipru(4)

2016-07-09 Thread Ian Sutton
On Wed, Jul 6, 2016 at 5:41 AM, Damien Miller wrote: > That sounds like a reasonable compromise - it would let the admin load > code to the PRUs in rc.securelevel for later use, or set > kern.securelevel=0 in sysctl.conf if they wanted to do development > on a multi-user