On 2022/03/12 11:35, Martin Pieuchot wrote:
> Try to allocate the buffer before doing the encryption, if it fails we
> do not spend time doing the encryption. This reduce the pressure when
> swapping with low memory.
Done a couple of ports bulk builds with this on i386, no problems seen.
On 2022/03/15 11:50, Marc Espie wrote:
> I've changed pkg_add for updates and tied files a while back, which resulted
> in creating a lot of temp files. The logic was complicated, and I didn't
> want to make it more complex at the time until most of the issues were fixed.
>
> Then we got tags, so
I've changed pkg_add for updates and tied files a while back, which resulted
in creating a lot of temp files. The logic was complicated, and I didn't
want to make it more complex at the time until most of the issues were fixed.
Then we got tags, so that most packing-lists are innocuous these
This removes the data dependency consumer barrier from the atomic_load_*
functions. I think the intent was to keep these functions relaxed in
terms of CPU memory order.
This makes these functions more agreeable in code that assertions may
use, such as the suggested refcnt_read().
Removing the
This patch adds a function for getting a snapshot of a reference
counter. This will let code like crcopy() access the value in an
API-observing way.
OK?
Index: share/man/man9/refcnt_init.9
===
RCS file:
On Tue, Mar 15, 2022 at 09:11:30AM +, Visa Hankala wrote:
> This patch adds a function for getting a snapshot of a reference
> counter. This will let code like crcopy() access the value in an
> API-observing way.
>
> OK?
ok mvs@
>
> Index: share/man/man9/refcnt_init.9
>
Make kqueue use the refcnt API.
OK?
Index: sys/kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.183
diff -u -p -r1.183 kern_event.c
--- sys/kern/kern_event.c 22 Feb 2022 01:15:01 -
This diff just refactors the code by moving the alloc part up.
It makes the code a bit easier to read and more similar with other
prefix_adjout functions. Also I plan to pass the struct prefix in
as an argument and do the prefix_adjout_get() in the callee.
--
:wq Claudio
Index: rde_rib.c
On Tue, Mar 15, 2022 at 12:21:00PM +0100, Claudio Jeker wrote:
> This diff just refactors the code by moving the alloc part up.
> It makes the code a bit easier to read and more similar with other
> prefix_adjout functions. Also I plan to pass the struct prefix in
> as an argument and do the
On Tue, Mar 15, 2022 at 09:11:30AM +, Visa Hankala wrote:
> This patch adds a function for getting a snapshot of a reference
> counter. This will let code like crcopy() access the value in an
> API-observing way.
Here is a revised version.
Based on input from dlg@, the patch now adds
Le Tue, Mar 15, 2022 at 04:03:20PM +0100, Claudio Jeker a écrit :
> Currently EoR markers use a full byte in struct prefix what can be done in
> a bit. Use the last flags field so that that 1 byte is available again.
> I already have a need for that byte this is why I came up with this
> change.
>
Currently EoR markers use a full byte in struct prefix what can be done in
a bit. Use the last flags field so that that 1 byte is available again.
I already have a need for that byte this is why I came up with this
change.
--
:wq Claudio
? obj
Index: rde.h
On Tue, Mar 15, 2022 at 04:03:20PM +0100, Claudio Jeker wrote:
> Currently EoR markers use a full byte in struct prefix what can be done in
> a bit. Use the last flags field so that that 1 byte is available again.
> I already have a need for that byte this is why I came up with this
> change.
ok
Errata patches for libcrypto bignum have been released for OpenBSD
6.9 and 7.0.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata69.html
Rather out of my depth but I ran into another instance of the problem
that's come up before with ctypes/C++ headers/xlocale (see also
https://marc.info/?l=openbsd-bugs=157758838031146=2 and
https://marc.info/?l=openbsd-bugs=161528248931449=2), i.e.
the C++ headers unconditionally depend on
> Date: Tue, 15 Mar 2022 20:59:07 +
> From: Stuart Henderson
>
> Rather out of my depth but I ran into another instance of the problem
> that's come up before with ctypes/C++ headers/xlocale (see also
> https://marc.info/?l=openbsd-bugs=157758838031146=2 and
>
16 matches
Mail list logo
