User Details
- User Since
- Mar 11 2014, 8:46 PM (531 w, 4 d)
Fri, May 17
Thu, May 16
FYI, I did tweak a few style things when pushing: 1) I moved the new extern variable declaration down next to the one other extern variable in the header (and in general type definitions are first before externs), and in kern_linker.c I rewrapped a few lines to fit in 80 cols.
Only amd64 and i386 successfully build with GCC currently. risc-v needs GCC's libatomic to link, powerpc and arm break in various ways. There's a reason that only amd64 GCC builds are enabled in CI. The toolchains do exist for all of our platforms, but getting things to build there is more of an aspiration.
Mon, May 13
Do you have this pushed to a public branch somewhere so I can cherry-pick it directly?
@ashafer_badland.io, do you need a committer to push this for you?
Fri, May 10
Might want a comment or a detail in the commit log that while the 0xff ID is used for broadcast IPIs for local APICs when not using x2APIC, IPIs aren't sent to I/O APICs, so it's ok for an I/O APIC to reuse that ID. Might also want to note that I/O APIC IDs haven't been meaningful since the 3-wire APIC bus which was last used by systems using Pentium CPUs.
Thu, May 9
Drop md.c change
Wed, May 8
Tue, May 7
Yeah, if it wasn't contrib'd code I'd hack it directly as well. On IRC yesterday there was some discussion about just removing it as unnecessary, and upstream should probably clean this up, but I think a Makefile hack is cleanest for us. I can push my version with Ed's stamp.
I used this patch locally since we have a builtin for this warning in bsd.sys.mk:
Mon, May 6
It's not really critical.
Supplanted by the two reviews noted earlier.
Hmm, I had originally written this for markj@ to look at as an alternative to the use of atomics / epoch. I do think this is probably easier to reason about at least. If we did go this route it would probably benefit from a followup to push the locking up a bit so that there is are fewer 'unlock/lock' patterns.