Re: [External] : better use the tokeniser in the pfctl parser

Hello, On Tue, Aug 31, 2021 at 02:40:57PM +1000, David Gwynne wrote: > handling the "no" option with a token, and "yes" via a string made my > eye twitch. > > ok? or is the helpful yyerror a nice feature? > I actually think it's a nice feature. below is output for current pfctl we have

better use the tokeniser in the pfctl parser

handling the "no" option with a token, and "yes" via a string made my eye twitch. ok? or is the helpful yyerror a nice feature? Index: parse.y === RCS file: /cvs/src/sbin/pfctl/parse.y,v retrieving revision 1.709 diff -u -p -r1.709 p

Re: [Patch] - Add -u (update packages) to sysupgrade(8)

On 2021-08-30 22:16 +0100, Stuart Henderson wrote: > On 2021/08/28 09:26, Sebastien Marie wrote: > > On Fri, Aug 27, 2021 at 08:17:51PM -0500, Aaron Poffenberger wrote: > > > Following is patch to add a flag to upgrade packages during > > > rc.firsttime after a sysupgrade. > > > > > > > if you n

Re: [Patch] - Add -u (update packages) to sysupgrade(8)

On 2021/08/28 09:26, Sebastien Marie wrote: > On Fri, Aug 27, 2021 at 08:17:51PM -0500, Aaron Poffenberger wrote: > > Following is patch to add a flag to upgrade packages during > > rc.firsttime after a sysupgrade. > > > > if you need this flag, is it a ponctual usage (running sysupgrade with > t

Re: relayd(8): agentx allow re-enabling

Martijn van Duren(openbsd+t...@list.imperialat.at) on 2021.08.30 12:50:23 +0200: > Via "relayctl reload" agentx can be enabled, disabled, but if it's > enabled->disabled->enabled the final enable won't work because we > never reset the sa. > > Also add an extra guard so that we don't accidentally

relayd(8): agentx allow re-enabling

Via "relayctl reload" agentx can be enabled, disabled, but if it's enabled->disabled->enabled the final enable won't work because we never reset the sa. Also add an extra guard so that we don't accidentally free it twice. OK? martijn@ Index: agentx_control.c

libagentx: Fix thumbling after free

I missed this one before, since apparently it doesn't show up with MALLOC_OPTIONS set to "S", but it does if it is empty. This probably effects relayd if the admin has it enabled en then disables it via a "relayctl reload". However, I'm not able to reproduce it there and even if it can be triggere

Re: systat(1) counter overflow

On 13/07/21(Tue) 00:55, Anindya Mukherjee wrote: > On Sat, Jul 03, 2021 at 11:20:42AM +0100, Stuart Henderson wrote: > > On 2021/07/03 01:09, Anindya Mukherjee wrote: > > > Thanks for the discussion. This has been very illuminating. I have been > > > digging > > > around in /usr/src/ and ignoring

Re: ddb trace: fix output for too many arguments

On Mon, Jul 12, 2021 at 08:18:20PM +0200, Mark Kettenis wrote: > > Date: Mon, 12 Jul 2021 20:11:30 +0200 > > From: Jasper Lievisse Adriaanse > > > > On Sun, Jul 11, 2021 at 03:58:05PM +0200, Jasper Lievisse Adriaanse wrote: > > > Hi, > > > > > > When printing a trace from ddb, some architectures

Re: Kill SYSCALL_DEBUG

> From: "Theo de Raadt" > Date: Mon, 30 Aug 2021 01:47:43 -0600 > > Hang on, SYSCALL_DEBUG is used to bring up new architectures. > That is the only time the #define is enabled. > > When you are bringing up a new architecture, bt is useless > > I don't think this makes sense. Indeed. This nee

Re: Kill SYSCALL_DEBUG

Hang on, SYSCALL_DEBUG is used to bring up new architectures. That is the only time the #define is enabled. When you are bringing up a new architecture, bt is useless I don't think this makes sense. Martin Pieuchot wrote: > Now that dt(4) and btrace(8) are enabled by default and provide a nice

Kill SYSCALL_DEBUG

Now that dt(4) and btrace(8) are enabled by default and provide a nice and flexible way to debug syscalls on GENERIC kernels should we get rid of the SYSCALL_DEBUG mechanism? Note that the auto-generated kern/syscalls.c providing the `syscallnames' array is still needed to build btrace(8). ok? I