- User Since
- Jul 4 2018, 7:23 PM (115 w, 3 d)
Fri, Sep 18
These are in contrib/netbsd-tests; will you be submitting this upstream? I note that our vendor copy is ancient; mutex6 was deleted upstream in December 2017, and the workaround for PR 44387 on PowerPC removed in March 2017.
Thu, Sep 10
So, whatever the right way to fix this is, RISC-V, AArch64, Arm and MIPS should all be changed in the same way. PowerPC seems to be as is done in this patch. IMO the eax argument is a waste of time, and it would be far better if the FBT code just looked at the trapframe to get out whatever set of registers it needs; it's clearer, it can get at more than just the one register and it avoids redundancy.
The original implementation is copied from AArch64. I'm not convinced this change is correct; RISC-V returns small structs in a0/a1, so this will miss half of such structs.
Sat, Sep 5
Aug 9 2020
Jul 29 2020
Jul 28 2020
- Can we please properly document where this magic value comes from?
Jul 26 2020
Jul 20 2020
Jul 19 2020
Jul 18 2020
Drop explicit (void *) cast. Clang's -pedantic wants it, but GCC's -pedantic complains about the cast itself as function pointer to object pointer casts are an optional extension in ISO C. Since we can't please everyone, go with the least-cluttered option and just drop it. Building FreeBSD with -pedantic is never going to happen anyway.
... back to the right patch
Fixed stray non-breaking space in comment
Jul 3 2020
Jul 2 2020
Also, please avoid filing revisions with CheriBSD tainting the diff; it can be misleading, as well as the fact that we're always a bit behind (and in this case it does matter because of the loader(8) patch landing).
arm64's parse_fdt_bootargs deals with loader(8) which will normally handle these for us when used, so we need to copy that approach given https://reviews.freebsd.org/D24912 has landed. My guess is the best place for it is parse_metadata around where we currently call init_static_kenv, to match arm64.
Jul 1 2020
Some more comments:
Are there not issues with a device driver disabling interrupts in its handler (either synchronous or asynchronous) for whatever reason and then that being clobbered by the plic_post_filter method? That already happened with pic_post_ithread... But we shouldn't need to disable/enable any more at all? An interrupt is suppressed the entire time we have it claimed, I assume the disable/enable code is there so we don't keep getting interrupts when using an ithread.
Jun 26 2020
Jun 25 2020
Jun 24 2020
Jun 23 2020
Jun 19 2020
Jun 18 2020
I don't know the details of loader, but this looks like a much better approach and doesn't perturb the SBI paths much so I'm happy.
Why are we doing this for GENERIC? No other architecture does so, and the only differences between them for GENERIC should be genuinely architecture-specific things, which TMPFS is not. If you want it for MFSROOT kernels, limit it to those. GENERIC is supposed to pick it up as a module just like everything else not required during earlyish boot.
Jun 17 2020
Jun 14 2020
Jun 12 2020
Patching the in-tree Clang to default to -mno-relax for FreeBSD might make sense. But out-of-tree can be used with BFD so that's not upstreamable.
Agreed; this is too big a hammer (and one day LLD will gain the ability to do the relaxations too; I posted a proof-of-concept for R_RISCV_ALIGN a couple of months ago and there was some activity from others).
Jun 10 2020
Jun 8 2020
Jun 7 2020
Jun 5 2020
FWIW, this series of three printf's was copied directly from arm64's pmap_bootstrap.
Jun 4 2020
May 21 2020
That's a holdover from the a.out days. See D21099.
May 19 2020
Yeah they don't need anything special, other than the ability to override KERNEL_LMA, which is kept here.
https://lists.denx.de/pipermail/u-boot/2020-February/401563.html suggests Linux is going the way of an alternate entry point, FWIW.
There is no guarantee that mhartid does not collide with the kernel's VA space. Unlikely, yes (especially since the spec encourages reducing the magnitude of the largest mhartid), but completely permitted. The only restriction on mhartid is this:
May 13 2020
May 7 2020
May 6 2020
Do we not need an equivalent change to the frustratingly-duplicated parts in lib/libc/gen/tls.c for statically-linked binaries? Initial-exec is unusual but still valid there so long as your linker has statically filled in the relocations for the GOT, and can happen if you disable TLS linker relaxation (or use one of the architectures that can't relax TLS sequences).