if you have multiple links to the same destination, this will let you
use them via route-to/reply-to/dup-to.
ok?
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1110
diff -u -p -r1.1110 pf.c
--- pf.c12
On Mon, Feb 15, 2021 at 08:02:37PM +1000, David Gwynne wrote:
> if you have multiple links to the same destination, this will let you
> use them via route-to/reply-to/dup-to.
>
> ok?
>
> Index: pf.c
> ===
> RCS file: /cvs/src/sys/net
Diagnostic function rw_enter_diag() should be called before
WITNESS_CHECKORDER() to have proper locking/debugging information.
In the case of 'locking against myself' it is currently impossible
to know where the lock has been previously acquired. Diff below fixes
that, ok?
Index: kern/kern_rwloc
Diff below includes non-functional changes:
- Sync comments with NetBSD including locking details.
- Remove superfluous parenthesis and spaces.
- Add brackets, even if questionable, to reduce diff with NetBSD
- Use for (;;) instead of while(1)
- Rename a variable from 'result' into 'error'.
- Move
On Sun, Feb 14, 2021 at 03:34:11PM +, Mikolaj Kucharski wrote:
> On Sun, Feb 14, 2021 at 03:22:28PM +0100, Marcus Glocker wrote:
> > Unfortunately I'm seeing more and more USB device breakages reported
> > the last few days related to the USB data toggle fix which we did
> > commit 2-3 weeks a
For SNI all TLS servers need to run with the same config. The config
parser has an extra step for this. The problem is it also compares the
TLS config params with non-TLS servers when a server block has both
listen * port 80 and listen * tls port 443.
The following diff fixes that and also removes
OK florian
On Mon, Feb 15, 2021 at 12:41:31PM +0100, Claudio Jeker wrote:
> For SNI all TLS servers need to run with the same config. The config
> parser has an extra step for this. The problem is it also compares the
> TLS config params with non-TLS servers when a server block has both
> listen *
On Mon, Feb 15, 2021 at 12:41:31PM +0100, Claudio Jeker wrote:
> For SNI all TLS servers need to run with the same config. The config
> parser has an extra step for this. The problem is it also compares the
> TLS config params with non-TLS servers when a server block has both
> listen * port 80 and
Hi,
I wouldn't mind to see such a feature in wsmouse, but there are two things
that I don't like about the patch in this form: 1) It breaks existing
configurations, and 2) it may bother the users who don't care about such an
extension - probably the majority of those who enable tapping.
A better
On 15/02/21(Mon) 11:47, Martin Pieuchot wrote:
> Diff below includes non-functional changes:
>
> - Sync comments with NetBSD including locking details.
> - Remove superfluous parenthesis and spaces.
> - Add brackets, even if questionable, to reduce diff with NetBSD
> - Use for (;;) instead of whil
Hi, I used your kernel to generate the dmesg below. Please have a look,
thanks!
OpenBSD 6.9-beta (GENERIC.MP) #310: Sun Feb 14 15:42:32 CET 2021
an...@desk.basename.se:/home/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34201006080 (32616MB)
avail mem = 33149136896 (31613MB)
random: good se
On Sun, Feb 14, 2021 at 05:41:55PM +, Job Snijders wrote:
> Make the AIA more easily available for debugging purposes & future
> changesets
>
> In the context of the RPKI, the AIA extension identifies the publication
> point of the certificate of the issuer of the certificate in which the
> ex
On Fri, Feb 12, 2021 at 10:01:38AM +0100, Claudio Jeker wrote:
> On Mon, Feb 08, 2021 at 05:15:40PM +0100, Claudio Jeker wrote:
> > Split the repository code into two parts:
> >
> > - fetch of the trust anchors (the certs referenced by TAL files)
> > - fetch of the MFT files of a repository
> >
>
On Mon, Feb 15, 2021 at 04:53:17PM +0100, Theo Buehler wrote:
> On Fri, Feb 12, 2021 at 10:01:38AM +0100, Claudio Jeker wrote:
> > On Mon, Feb 08, 2021 at 05:15:40PM +0100, Claudio Jeker wrote:
> > > Split the repository code into two parts:
> > >
> > > - fetch of the trust anchors (the certs refe
On Wed, Feb 10, 2021 at 05:30:02PM +0100, Claudio Jeker wrote:
> On Tue, Jan 26, 2021 at 10:31:40AM +0100, Claudio Jeker wrote:
> > This diff adds initial RTR (RPKI to Router) support to bgpd.
> > Instead of loading the roa-set table via the configuration bgpd will use
> > RTR to load the RPKI tabl
> > > rt.repos = reallocarray(rt.repos,
> > > rt.reposz + 1, sizeof(struct repo));
> >
> > This line could be unwrapped. The code could also be simplified by using
> > recallocarray() (it looks like the -portable update.sh is prepared for
> > that).
>
> I leave that for later. There a
On Mon, Feb 15, 2021 at 11:37:45AM +0100, Martin Pieuchot wrote:
> Diagnostic function rw_enter_diag() should be called before
> WITNESS_CHECKORDER() to have proper locking/debugging information.
>
> In the case of 'locking against myself' it is currently impossible
> to know where the lock has be
Hi,
Thank you for the review
On Mon, Feb 15, 2021 at 01:42:57PM +0100, Claudio Jeker wrote:
> Please do not define variables in the middle of functions.
now fixed
> > + AUTHORITY_INFO_ACCESS_free(info);
> > +
> > + return aia;
> > +}
>
> I really don't like the way x509_get_aia() is diffe
On Mon, Feb 15, 2021 at 04:58:50PM +, Job Snijders wrote:
> Hi,
>
> Thank you for the review
>
> On Mon, Feb 15, 2021 at 01:42:57PM +0100, Claudio Jeker wrote:
> > Please do not define variables in the middle of functions.
>
> now fixed
>
> > > + AUTHORITY_INFO_ACCESS_free(info);
> > > +
>
On 21-02-15 14:49:46, Jan Klemkow wrote:
> On Sat, Feb 13, 2021 at 03:53:48PM +0100, Theo Buehler wrote:
> > On Sat, Feb 13, 2021 at 11:58:04AM +0100, Jan Klemkow wrote:
> > > A coworker of mine has made tests with LibreSSL [1] and found some
> > > regressions. I took his test descriptions and cre
On Sat, Feb 13, 2021 at 03:53:48PM +0100, Theo Buehler wrote:
> On Sat, Feb 13, 2021 at 11:58:04AM +0100, Jan Klemkow wrote:
> > A coworker of mine has made tests with LibreSSL [1] and found some
> > regressions. I took his test descriptions and created the following
> > automated regression test.
On Tue, Feb 16, 2021 at 04:36:59AM +1100, Joel Sing wrote:
> On 21-02-15 14:49:46, Jan Klemkow wrote:
> > On Sat, Feb 13, 2021 at 03:53:48PM +0100, Theo Buehler wrote:
> > > On Sat, Feb 13, 2021 at 11:58:04AM +0100, Jan Klemkow wrote:
> > > > A coworker of mine has made tests with LibreSSL [1] and
> Date: Mon, 15 Feb 2021 01:19:29 +0100
> From: Patrick Wildt
>
> Am Mon, Feb 15, 2021 at 09:55:56AM +1000 schrieb David Gwynne:
> >
> >
> > > On 15 Feb 2021, at 07:54, Mark Kettenis wrote:
> > >
> > > One of the aspects of device access is whether CPU writes to a device
> > > are posted or n
On Mon, Feb 15, 2021 at 01:15:33PM +0100, Martin Pieuchot wrote:
> On 15/02/21(Mon) 11:47, Martin Pieuchot wrote:
> > Diff below includes non-functional changes:
> >
> > - Sync comments with NetBSD including locking details.
> > - Remove superfluous parenthesis and spaces.
> > - Add brackets, even
On Sun, Feb 14 2021, Christian Weisgerber wrote:
> Christian Weisgerber:
>
>> > Make use of getline(3) in ftp(1).
>> >
>> > Replace fparseln(3) with getline(3). This removes the only use
>> > of libutil.a(fparseln.o) from the ramdisk.
>> > Replace a complicated fgetln(3) idiom with the much simp
On Tue, Feb 16, 2021 at 04:36:59AM +1100, Joel Sing wrote:
> On 21-02-15 14:49:46, Jan Klemkow wrote:
> > +create-libressl-test-certs: create-libressl-test-certs.pl
> > + ${PERL} ${.CURDIR}/$@.pl
>
> We can see how this goes, however we may end up wanting to generate
> the certificates and commi
> On 16 Feb 2021, at 06:01, Mark Kettenis wrote:
>
>> Date: Mon, 15 Feb 2021 01:19:29 +0100
>> From: Patrick Wildt
>>
>> Am Mon, Feb 15, 2021 at 09:55:56AM +1000 schrieb David Gwynne:
>>>
>>>
On 15 Feb 2021, at 07:54, Mark Kettenis wrote:
One of the aspects of device acces
> > > +# server certificate where SAN contains in-label wildcards which are
> > > allowed by
> > > +# RFC 6125
> >
> > It is worth noting that per the RFC, a client MAY allow in-label
> > wildcards (this is not a MUST or even a SHOULD). Additionally,
> > various software does not allow or support
On Mon, Feb 08, 2021 at 10:48:26AM +0100, Sven Wolf wrote:
> Hi,
>
> thanks for your fast response.
> I've chosen "AMD 17_3X_IOMMU" instead of "Starship/Matisse" because in my
> point of view, also the other Ryzen Zen 2 pci devices were named 17_3x (e.g.
> PCI_PRODUCT_AMD_17_3X_RC 0x1480 /* 17h/3x
29 matches
Mail list logo