Phil Eaton wrote:
> Hey,
>
> Doas currently tells you the line but not the column for syntax errors. In
> the case of a missing newline at the end of a line I was confused. So I
> added the column number to the message as well.
>
> Also, is there any interest in relaxing the grammar so a traili
On Sun, Jul 08, 2018 at 06:38:16PM +0200, Jeremie Courreges-Anglas wrote:
>
> When looking at the recent changes in this file I noticed that the
> presence of both ber_read() and ber_readbuf() was due to an incomplete
> cleanup from my part.
>
> revision 1.32
> date: 2018/02/08 18:02:06; aut
On Mon, Jul 09, 2018 at 01:21:25AM -0600, Theo de Raadt wrote:
> Phil Eaton wrote:
>
> > Hey,
> >
> > Doas currently tells you the line but not the column for syntax errors. In
> > the case of a missing newline at the end of a line I was confused. So I
> > added the column number to the message
> Date: Mon, 9 Jul 2018 14:23:43 +1000
> From: Jonathan Matthew
>
> This started out as a port of freebsd's bnxt driver, but along the way I
> had to rewrite the interesting bits.
>
> NetXtreme-C/E (BCM573xx and BCM574xx) is a different line of chips to
> NetXtreme II 10G (BCM577xx, which mje wa
Otto Moerbeek wrote:
> On Mon, Jul 09, 2018 at 01:21:25AM -0600, Theo de Raadt wrote:
>
> > Phil Eaton wrote:
> >
> > > Hey,
> > >
> > > Doas currently tells you the line but not the column for syntax errors. In
> > > the case of a missing newline at the end of a line I was confused. So I
> >
On Mon, Jul 09, 2018 at 01:52:29AM -0600, Theo de Raadt wrote:
> Otto Moerbeek wrote:
>
> > On Mon, Jul 09, 2018 at 01:21:25AM -0600, Theo de Raadt wrote:
> >
> > > Phil Eaton wrote:
> > >
> > > > Hey,
> > > >
> > > > Doas currently tells you the line but not the column for syntax errors.
>
later on it is set with:
log_setverbose(ospfd_conf->opts & OSPFD_OPT_VERBOSE);
OK?
Index: ospf6d.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/ospf6d.c,v
retrieving revision 1.35
diff -u -p -r1.35 ospf6d.c
--- ospf6d.c5 Nov 2017 16:5
On Mon, Jul 09, 2018 at 10:31:15AM +0200, Remi Locherer wrote:
> later on it is set with:
> log_setverbose(ospfd_conf->opts & OSPFD_OPT_VERBOSE);
>
> OK?
Shouldn't we instead remove the log_setverbose(1) above the getopt call?
I think the idea is that we want to be able to print debug messages
be
On 03/07/18(Tue) 12:38, Martin Pieuchot wrote:
> The next important step towards removing the KERNEL_LOCK() from the
> kernel is to be able to execute ioctl(2)s without it.
>
> The first area that can benefit from this is obviously the Network
> Stack. tb@ and kn@ are working on this area so they
On Sat, 26 May 2018 22:44:56 +0930
Jack Burton wrote:
> This diff adds three new TLS_PEER_* fastcgi variables: ISSUER, SERIAL
> & SUBJECT.
>
> That seems the logical next step in making tls client certs usable for
> authorisation & accounting. Last week's commit (thanks Joel!) took
> care of auth
On Mon, Jul 09, 2018 at 10:42:16AM +0200, Claudio Jeker wrote:
> On Mon, Jul 09, 2018 at 10:31:15AM +0200, Remi Locherer wrote:
> > later on it is set with:
> > log_setverbose(ospfd_conf->opts & OSPFD_OPT_VERBOSE);
> >
> > OK?
>
> Shouldn't we instead remove the log_setverbose(1) above the getopt
On Mon, Jul 09 2018, Remi Locherer wrote:
> On Mon, Jul 09, 2018 at 10:42:16AM +0200, Claudio Jeker wrote:
>> On Mon, Jul 09, 2018 at 10:31:15AM +0200, Remi Locherer wrote:
>> > later on it is set with:
>> > log_setverbose(ospfd_conf->opts & OSPFD_OPT_VERBOSE);
>> >
>> > OK?
>>
>> Shouldn't we i
On Mon, Jul 09, 2018 at 11:33:05AM +0200, Remi Locherer wrote:
> On Mon, Jul 09, 2018 at 10:42:16AM +0200, Claudio Jeker wrote:
> > On Mon, Jul 09, 2018 at 10:31:15AM +0200, Remi Locherer wrote:
> > > later on it is set with:
> > > log_setverbose(ospfd_conf->opts & OSPFD_OPT_VERBOSE);
> > >
> > >
raw_usrreq() is just unneeded abstraction. It is easier to just handle
all the PRU cases in route_usrreq() instead. Simplifies a few things
and will hopefully make further MP work easier.
This is a mix of raw_usrreq() and uipc_usrreq() (I think that raw_usrreq
is leaking mbufs in some cases). rout
Same kind of diff done for rtsock applied to pfkeyv2.
This is using a simplified version of route_usrreq() mainly because
PRU_RCVD is unused.
Quick testing with iked done, more checking welcome
--
:wq Claudio
Index: net/pfkeyv2.c
==
Thanks for the comments. Happy to take a stab at going the bc/bc.y route if
that seems acceptable. That yyerror handler looks much more helpful.
On Mon, Jul 9, 2018 at 4:04 AM Otto Moerbeek wrote:
> On Mon, Jul 09, 2018 at 01:52:29AM -0600, Theo de Raadt wrote:
>
> > Otto Moerbeek wrote:
> >
>
No need to duplicate the same block over and over again.
Just check it when we increment the counter and return failure if we hit
the limit.
OK?
--
:wq Claudio
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving rev
On Mon, Jul 09, 2018 at 01:19:52PM +0200, Claudio Jeker wrote:
> raw_usrreq() is just unneeded abstraction. It is easier to just handle
> all the PRU cases in route_usrreq() instead. Simplifies a few things
> and will hopefully make further MP work easier.
>
> This is a mix of raw_usrreq() and uip
Hi,
Would this change make it simpler to diagnose a vmm crash?
Nayden
Index: arch/amd64/amd64/vmm.c
===
RCS file: /home/nayden/cvsync/src/sys/arch/amd64/amd64/vmm.c,v
retrieving revision 1.207
diff -u -p -r1.207 vmm.c
--- arch/amd
On Mon, Jul 09, 2018 at 07:08:14AM -0600, nayden wrote:
>
> Hi,
>
> Would this change make it simpler to diagnose a vmm crash?
>
> Nayden
>
sure, go ahead.
> Index: arch/amd64/amd64/vmm.c
> ===
> RCS file: /home/nayden/cvsync/src
On Mon, Jul 09, 2018 at 01:51:59PM +0200, Claudio Jeker wrote:
> Same kind of diff done for rtsock applied to pfkeyv2.
> This is using a simplified version of route_usrreq() mainly because
> PRU_RCVD is unused.
>
> Quick testing with iked done, more checking welcome
passes ipsec regress; OK bluhm
On Mon, Jul 09, 2018 at 11:38:13AM +1000, Jonathan Gray wrote:
> On Sun, Jul 08, 2018 at 12:15:39PM -0700, Thomas Frohwein wrote:
> > Hi,
> >
> > It appears that HD Audio from AMD's generation Ryzen can't handle MSI.
> > This leads to the bug that I reported here:
> >
> > https://marc.info/?l=ope
Similar to the rde_filter code there is no need to path_get() the aspath
used in rde_update_dispatch(). Also makes the code a bit easier since the
cleanup can be done all the time.
--
:wq Claudio
Index: rde.c
===
RCS file: /cvs/src
I am late for a comment because it has already been commited but...
> @@ -1373,6 +1339,14 @@ rde_update_update(struct rde_peer *peer,
> if (path_update(&ribs[RIB_ADJ_IN].rib, peer, asp, prefix, prefixlen, 0))
> peer->prefix_cnt++;
>
> + /* max prefix checker */
> + if
On Mon, Jul 09, 2018 at 05:50:07PM +0200, Denis Fondras wrote:
> I am late for a comment because it has already been commited but...
>
> > @@ -1373,6 +1339,14 @@ rde_update_update(struct rde_peer *peer,
> > if (path_update(&ribs[RIB_ADJ_IN].rib, peer, asp, prefix, prefixlen, 0))
> >
On Mon, Jul 09, 2018 at 05:47:11PM +0200, Claudio Jeker wrote:
> Similar to the rde_filter code there is no need to path_get() the aspath
> used in rde_update_dispatch(). Also makes the code a bit easier since the
> cleanup can be done all the time.
>
looks good, compiles fine, runs well, OK deni
raw_usrreq() is no longer used so remove it from the tree.
The only thing form the headerfile that was still used was RAWSNDQ and
RAWRCVQ. I replaced them with per protocol defines.
OK?
--
:wq Claudio
Index: conf/files
===
RCS file:
On Mon, Jul 09, 2018 at 10:04:35AM +0200, Otto Moerbeek wrote:
Hello Otto,
>> I still don't see the point. In 30 years, I've gotten by with parsers
>> that say "syntax error", and had very bad experiences with programs that
>> do a poor job anticipating where the parse error is. Of course there
On Sun, Jul 1, 2018 at 9:47 AM Joerg Sonnenberger wrote:
> On Fri, Jun 29, 2018 at 04:21:17PM +0200, Alexander Bluhm wrote:
> > The problem is that POSIX has signals that are sent to processes
> > and signals sent to individual threads. Our kernel does not support
> > this properly.
>
> Well, no
On Mon, Jul 09, 2018 at 11:27:55AM -0900, Philip Guenther wrote:
> Those signals are handled by the first thread that
> > doesn't have them masked. In that case, it should be put on the pending
> > list of the process and any unmasking operation should check the pending
> > list on whether a signal
Actually free the right thing in rib_free()
Found by and with claudio.
(benno_claudio_rde_rib_rib_free.diff)
Index: rde_rib.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_rib.c,v
retrieving revision 1.167
diff -u -p -r1.167 rde_rib.c
---
ok
Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.07.09 19:20:35 +0200:
> raw_usrreq() is no longer used so remove it from the tree.
> The only thing form the headerfile that was still used was RAWSNDQ and
> RAWRCVQ. I replaced them with per protocol defines.
>
> OK?
> --
> :wq Claudio
>
> Ind
compare the right things here: we want to know if the flag has changed.
Found with claudios help and patience.
ok?
(benno_claudio_rde_reconf_F_RIB_HASNOFIB.diff)
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving
On Mon, Jul 09, 2018 at 11:45:41PM +0200, Sebastian Benoit wrote:
> Actually free the right thing in rib_free()
> Found by and with claudio.
>
> (benno_claudio_rde_rib_rib_free.diff)
OK claudio@
> Index: rde_rib.c
> ===
> RCS file:
On Mon, Jul 09, 2018 at 11:58:05PM +0200, Sebastian Benoit wrote:
>
> compare the right things here: we want to know if the flag has changed.
> Found with claudios help and patience.
>
> ok?
This is fucked up. :)
> (benno_claudio_rde_reconf_F_RIB_HASNOFIB.diff)
>
> Index: rde.c
>
Sebastian Benoit(be...@openbsd.org) on 2018.07.10 00:06:06 +0200:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.07.10 00:05:08 +0200:
> > On Mon, Jul 09, 2018 at 11:58:05PM +0200, Sebastian Benoit wrote:
> > >
> > > compare the right things here: we want to know if the flag has changed.
> > >
On Tue, Jul 10, 2018 at 12:07:04AM +0200, Sebastian Benoit wrote:
> Sebastian Benoit(be...@openbsd.org) on 2018.07.10 00:06:06 +0200:
> > Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.07.10 00:05:08 +0200:
> > > On Mon, Jul 09, 2018 at 11:58:05PM +0200, Sebastian Benoit wrote:
> > > >
> > > > co
i don't have the hardware to test, but im pretty confident this is
ok.
ok?
Index: pccbb.c
===
RCS file: /cvs/src/sys/dev/pci/pccbb.c,v
retrieving revision 1.97
diff -u -p -r1.97 pccbb.c
--- pccbb.c 8 Sep 2017 05:36:52 -
38 matches
Mail list logo
