On Sun, Oct 24, 2021 at 02:27:55PM +0200, Frederic Cambus wrote:
> Hi tech@,
>
> This diff removes mentions of ld warning messages for mktemp(3),
> tmpnam(3), and tempnam(3).
>
> LLD doesn't emit warnings when encountering .gnu.warning.* sections, so
> those warnings are not emitted anymore for a
But why?
So I thought APIWARN was to be naunced, so that there are two kinds: API
we always bitch about, and ones we only bitch about if APIWARN is set
(which allows a linker later on to decide if it wants to honour the
.section)
But you are throwing them all behind the #ifdef, which means the wa
Hi tech@,
Most (but not all) __warn_references occurences in libc are wrapped in
#if defined(APIWARN) blocks. This diff wraps the remaining occurences,
so building libc without the APIWARN definition does not produce any
strain .gnu.warning.* sections.
Comments? OK?
Index: lib/libc/compat-43/get
ooops, sorry not trondd, it was jhuldtgren who spotted it!
On 2021/10/24 22:26, Stuart Henderson wrote:
> trondd noticed a startup problem with snmpd on mips64 but didn't see
> them on amd64 and wondered if it was arch-specific, I had a go at
> reproducing and see it very often on aarch64 and also
trondd noticed a startup problem with snmpd on mips64 but didn't see
them on amd64 and wondered if it was arch-specific, I had a go at
reproducing and see it very often on aarch64 and also sometimes on
amd64.
Any setting of "trap receiver $ip snmpv2c community $community"
triggers the problem:
#
On Sun, Oct 24, 2021 at 03:03:01PM +0200, Damien Couderc wrote:
> Hi,
> I got a page fault with upd(4) since 7.0.
>
> The problem began with the last revision of upd.c (1.30):
>
> ===
> RCS file: /cvs/src/sys/dev/usb/upd.c,v
> retrie
On Sun, Oct 24, 2021 at 08:01:49PM +0200, Tobias Heider wrote:
> On Sun, Oct 24, 2021 at 07:16:27PM +0200, Tobias Heider wrote:
> > On Sun, Oct 24, 2021 at 07:10:22PM +0200, Tobias Heider wrote:
> > > The diff below removes ipcomp_input_cb(), ipcomp_output_cb() and some
> > > other
> > > things re
On Sun, Oct 24, 2021 at 07:16:27PM +0200, Tobias Heider wrote:
> On Sun, Oct 24, 2021 at 07:10:22PM +0200, Tobias Heider wrote:
> > The diff below removes ipcomp_input_cb(), ipcomp_output_cb() and some other
> > things related to the old crypto API.
> >
> > ok?
>
> small update to move ip6_hdr ou
On Sun, Oct 24, 2021 at 06:39:42PM +0100, Martijn van Duren wrote:
> libagentx currently allows OIDs with a length of 0.
> This isn't wrong from an agentx protocol point of view, but ber encoding
> can't handle OIDs with less then 2 elements, which makes it unable to
> map the values back to SNMP.
On Sun, Oct 24, 2021 at 07:43:44PM +0200, Claudio Jeker wrote:
> This diff adds the print functions from the regress test to rpki-client.
> Currently not hooked up in rpki-client itself but that will follow soon.
ok tb
Hi,
This removes some code duplication by merging the v4 and v6 input
functions.
Basically common code is moved into ipsec_protoff() which finds the
offset of the next protocol field in the previous header.
ok?
bluhm
Index: netinet/in_proto.c
===
On Sun, Oct 24, 2021 at 06:31:29PM +0100, Martijn van Duren wrote:
> This diff should be superfluous with the next diff, but I don't think
> this should be left as is anyway.
>
> It's not a big problem, since it's a static buffer and it gets
> initialized by previous calls, so it's always NUL-term
This diff adds the print functions from the regress test to rpki-client.
Currently not hooked up in rpki-client itself but that will follow soon.
--
:wq Claudio
Index: usr.sbin/rpki-client/extern.h
===
RCS file: /cvs/src/usr.sbin/rp
libagentx currently allows OIDs with a length of 0.
This isn't wrong from an agentx protocol point of view, but ber encoding
can't handle OIDs with less then 2 elements, which makes it unable to
map the values back to SNMP. netsnmp maps a null-oid to 0.0, but I don't
think we should do that.
This
This diff should be superfluous with the next diff, but I don't think
this should be left as is anyway.
It's not a big problem, since it's a static buffer and it gets
initialized by previous calls, so it's always NUL-terminated, but
it's not accurate.
OK?
martijn@
Index: ax.c
==
> On 24 Oct 2021, at 19:00, Alexander Bluhm wrote:
>
> On Sun, Oct 24, 2021 at 02:52:45AM +0200, Alexander Bluhm wrote:
>> There are more m_pullup()s in IPsec input. Pass down the pointer
>> to the mbuf. At the end it will reach ip_deliver() which expects
>> a pointer to an mbuf anyway.
>
> Me
On Sun, Oct 24, 2021 at 07:10:22PM +0200, Tobias Heider wrote:
> The diff below removes ipcomp_input_cb(), ipcomp_output_cb() and some other
> things related to the old crypto API.
>
> ok?
small update to move ip6_hdr out of '#if NBPFILTER > 0'
Index: ip_ipcomp.c
The diff below removes ipcomp_input_cb(), ipcomp_output_cb() and some other
things related to the old crypto API.
ok?
Index: ip_ipcomp.c
===
RCS file: /cvs/src/sys/netinet/ip_ipcomp.c,v
retrieving revision 1.84
diff -u -p -r1.84 ip_i
On Sun, Oct 24, 2021 at 06:00:59PM +0200, Alexander Bluhm wrote:
> On Sun, Oct 24, 2021 at 02:52:45AM +0200, Alexander Bluhm wrote:
> > There are more m_pullup()s in IPsec input. Pass down the pointer
> > to the mbuf. At the end it will reach ip_deliver() which expects
> > a pointer to an mbuf an
clang(1) defaults to FP ABI but ld(1) -melf64lriscv doesn't. This is
a problem as soon as a port tries to use raw ld(1) -b binary to embed
data in a .o file.
Downgrading this hard error to a warning seems more useful as far as the
ports tree is concerned. The diff below fixes
databases/postgre
On Sun, Oct 24, 2021 at 02:52:45AM +0200, Alexander Bluhm wrote:
> There are more m_pullup()s in IPsec input. Pass down the pointer
> to the mbuf. At the end it will reach ip_deliver() which expects
> a pointer to an mbuf anyway.
Merged to -current.
ok?
bluhm
Index: netinet/ip_ah.c
==
On Sun, Oct 24, 2021 at 05:21:35PM +0200, Tobias Heider wrote:
> On Sun, Oct 24, 2021 at 05:05:06PM +0200, Tobias Heider wrote:
> > On Sat, Oct 23, 2021 at 10:17:54PM +0200, Tobias Heider wrote:
> > > The diff below removes a few leftover tdb_crypto allocations in
> > > esp_input()
> > > and esp_o
On Sun, Oct 24, 2021 at 05:05:06PM +0200, Tobias Heider wrote:
> On Sat, Oct 23, 2021 at 10:17:54PM +0200, Tobias Heider wrote:
> > The diff below removes a few leftover tdb_crypto allocations in esp_input()
> > and esp_output(). The allocations were needed to pass arguments to the
> > callback fu
On Sat, Oct 23, 2021 at 10:17:54PM +0200, Tobias Heider wrote:
> The diff below removes a few leftover tdb_crypto allocations in esp_input()
> and esp_output(). The allocations were needed to pass arguments to the
> callback function with the non-blocking crypto API and are redundant now
> that cr
> Date: Sun, 24 Oct 2021 15:14:14 +0100
> From: Martin Pieuchot
>
> On 24/10/21(Sun) 14:49, Martin Pieuchot wrote:
> > Here's another small tweak I could extract from the UVM unlocking diff.
> > This doesn't introduce any functional change. uvm_km_pgremove() is used
> > in only one place.
>
> Up
On 24/10/21(Sun) 14:49, Martin Pieuchot wrote:
> Here's another small tweak I could extract from the UVM unlocking diff.
> This doesn't introduce any functional change. uvm_km_pgremove() is used
> in only one place.
Updated diff that also moves pmap_kremove() into the intrsafe variant to
be cohere
Here's another small tweak I could extract from the UVM unlocking diff.
This doesn't introduce any functional change. uvm_km_pgremove() is used
in only one place.
Ok?
Index: uvm/uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retr
At the last hackathon I observed high elapsed time when the unhibernate
bsd.booted kernel attaches unneccessary drivers, and then detatches a
vast number of them when suspending to bounce to the old image.
This diff skips attaching those devices. The current list is all tape
and network devices (
Hi,
I got a page fault with upd(4) since 7.0.
The problem began with the last revision of upd.c (1.30):
===
RCS file: /cvs/src/sys/dev/usb/upd.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- src/sys/d
On Sun, Oct 24, 2021 at 01:24:23PM +0100, Stuart Henderson wrote:
> On 2021/10/24 11:57, Klemens Nanni wrote:
> > On Sun, Oct 24, 2021 at 12:41:11PM +0100, Stuart Henderson wrote:
> > > On 2021/10/24 11:20, Klemens Nanni wrote:
> > > > @@ -174,7 +174,7 @@ The following
> > > > example creates a ho
Hi tech@,
This diff removes mentions of ld warning messages for mktemp(3),
tmpnam(3), and tempnam(3).
LLD doesn't emit warnings when encountering .gnu.warning.* sections, so
those warnings are not emitted anymore for a majority of users since we
switched to LLD as the default linker on most archi
On 2021/10/24 11:57, Klemens Nanni wrote:
> On Sun, Oct 24, 2021 at 12:41:11PM +0100, Stuart Henderson wrote:
> > On 2021/10/24 11:20, Klemens Nanni wrote:
> > > @@ -174,7 +174,7 @@ The following
> > > example creates a host-based access point on boot:
> > > .Bd -literal -offset indent
> > > med
On Sun, Oct 24, 2021 at 12:41:11PM +0100, Stuart Henderson wrote:
> On 2021/10/24 11:20, Klemens Nanni wrote:
> > @@ -174,7 +174,7 @@ The following
> > example creates a host-based access point on boot:
> > .Bd -literal -offset indent
> > mediaopt hostap
> > -nwid mynwid nwkey mywepkey
> > +join
On 2021/10/24 11:20, Klemens Nanni wrote:
> @@ -174,7 +174,7 @@ The following
> example creates a host-based access point on boot:
> .Bd -literal -offset indent
> mediaopt hostap
> -nwid mynwid nwkey mywepkey
> +join mynwid nwkey mywepkey
> inet 192.168.1.1 255.255.255.0
that's not right for h
yes, we are ready.
Klemens Nanni wrote:
> I reckon the adoption of `join' was fairly successful and lots of people
> use it exclusively, so upon install I suggest to provide hostname.if(5)
> using it instead of `nwid'.
>
> Likewise, reflect that trend in our driver manuals.
>
> Feedback? Objec
I reckon the adoption of `join' was fairly successful and lots of people
use it exclusively, so upon install I suggest to provide hostname.if(5)
using it instead of `nwid'.
Likewise, reflect that trend in our driver manuals.
Feedback? Objection? OK?
Index: distrib/miniroot/install.sub
=
On Sun, Oct 24, 2021 at 11:32:26AM +0100, Stuart Henderson wrote:
> The minimum needs to go up too, a cvs checkout is 1.3G already.
>
> (Not that I use auto defaults without changes anyway, they don't
> work too well for ports dev..)
Changed minimum to 1.5G.
diff --git regress/sbin/disklabel/120
On 2021/10/24 13:10, Mikhail wrote:
> Hello, current maximum size of /usr/src in large disk autoinstall
> configuration is set to 2G, which in insufficient for 'git clone', where
> the repo already exceeded this size, I suggest to change it to 3G, since
> most users have disks large enough to handl
Hello, current maximum size of /usr/src in large disk autoinstall
configuration is set to 2G, which in insufficient for 'git clone', where
the repo already exceeded this size, I suggest to change it to 3G, since
most users have disks large enough to handle it.
diff --git regress/sbin/disklabel/300
39 matches
Mail list logo
