User Details
- User Since
- Mar 22 2019, 4:46 AM (218 w, 6 d)
Tue, May 30
Ugh, I did not test it properly, and I think this version is totally broken...
In the future, please leave the revision open long enough for reviewers to have a chance to look at it. Even though the change is straightforward, and it was accepted by Mark, maybe I would have seen something that he didn't. For me, the change came and went completely before I got back from lunch. Thanks!
Rework the change; remove pmc_can_attach() entirely in favor of p_candebug().
Add few more tweaks. Remove the type changes.
Mon, May 29
Sat, May 27
There are further improvements to be made here, will update after some investigation.
Fri, May 26
Once I've landed the first few of these I will handle the remaining ops.
Thu, May 25
LGTM, thanks. I can push this to the main branch.
Wed, May 24
Tue, May 23
Link to the root of the src repo.
I forgot to submit this a while ago when I purged this info from hier(7).
Mon, May 22
Thanks! ...especially for the ordering fix :)
Thanks. I will commit this and D39820 today or tomorrow.
I am having difficulty trying to rationalize the acronym "FIQ" 🤔 😆
Sat, May 20
Looks good, one thing to fix.
Fri, May 19
Tue, May 16
Absorbed by D39811.
Rebase.
Rebase. This patch becomes much simpler.
Rethink the series again; third time's the charm.
Mon, May 15
In order for this to work, you will need to fix the assembly in locore.S where we actually create the devmap mapping. There, we create it as a single 2MiB page beginning at (VM_MAX_KERNEL_ADDRESS - L2_SIZE).
Thanks for your work in handling this, @karels. The pw(8) changes, and tests, make sense to me, but it's not really my code to accept.
Fri, May 12
The wording used by the docs is confusing, but it is actually saying that disassemblers should output the aliases when possible.
Thu, May 11
I think the major version bump for 14.0 is a good thing, after going unchanged for a long while. I am certain that backwards compatibility has not been tested thoroughly in the last couple of years, and there are probably some subtle edge cases in which it has broken (for all I know I could be the culprit). This gives us a new baseline.
It is annoying, but this represents a new distinct error return from the syscall, and should be added to the ERRORS list in hwpmc(4).
The resulting cleanup is excellent.
Wed, May 10
Tue, May 9
Rebase and rename to printcpuinfo().
Rework the change a bit based on review comments.
This is simple, and makes sense to me. I think you should be consistent about which interpreter variant is the "yes" one; for efi and userboot it is "simp" but for i386 it is "4th".