On Fri, Dec 2, 2022 at 3:17 PM Jeremie Courreges-Anglas
wrote:
>
> WEAK_REFERENCE seems to come from FreeBSD, it's not used in our tree.
> (WEAK_ALIAS is defined a few lines above).
>
> ok?
>
ok guenther@
On Sat, Dec 03, 2022 at 11:48:16PM +0100, Jeremie Courreges-Anglas wrote:
>
> With the diff below we get more details about the SBI version running on
> the machine. My Unmatched machine has OpenBSD version 0.9 but upstream
> has released 1.1 since, it implements v0.2 of the SBI spec but 0.3 and
On Sat, Dec 03, 2022 at 01:15:09AM +0100, Jeremie Courreges-Anglas wrote:
>
> ok?
>
>
Probably needs cheloha@'s ok but this looks ok to me.
-ml
> Index: clock.c
> ===
> RCS file: /cvs/src/sys/arch/riscv64/riscv64/clock.c,v
> retr
On Sat, Dec 03, 2022 at 12:16:43AM +0100, Jeremie Courreges-Anglas wrote:
>
> WEAK_REFERENCE seems to come from FreeBSD, it's not used in our tree.
> (WEAK_ALIAS is defined a few lines above).
>
> ok?
>
ok mlarkin if you didnt get to it already
>
> Index: sys/arch/riscv64/include/asm.h
>
Hello,
>
> pf_test_rule uses the skw and sks pointers after pf_state_insert sets
> them via pf_create_state. i would happily change pf_test rule so it
> reads the pf_state_key pointers out of pf_state rather than carry them
> around on the stack like that, but i figured the diff was big enough as
It is time.
ok deraadt
There is a man page change we've discussed which can also go in, after
that I expect jmc will get involved and change it a little.
Andrew and I have had another discussion about how the installer might
provide a way in the installer to create these files instead (no new
qu
On Mon, Dec 05, 2022 at 11:26:21AM +0100, Alexandr Nedvedicky wrote:
> Hello,
> On Mon, Dec 05, 2022 at 11:46:07AM +1000, David Gwynne wrote:
> >
> > yes, you're right. the diff below includes the simple fix to that.
> >
> > this demonstrates how subtle the reference counting around the trees
> >
Hello,
On Mon, Dec 05, 2022 at 11:46:07AM +1000, David Gwynne wrote:
>
> yes, you're right. the diff below includes the simple fix to that.
>
> this demonstrates how subtle the reference counting around the trees
> is though. maybe it would be more obvious to take another refcnt
> before giving t
