This is consistent with pmap_l3_valid(), for instance. Fix style bugs
along the way. No functional change intended.
Details
- Reviewers
br jhb - Commits
- rS341807: Use inline tests for individual PTE bits in the RISC-V pmap.
Booted under QEMU and spike.
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 21410 Build 20733: arc lint + arc unit
Event Timeline
sys/riscv/riscv/pmap.c | ||
---|---|---|
360 | If we support superpages eventually then we might not want l3 in this name? That might be true for pmap_l3_valid as well? (Or will we only use this function on leaf PTEs?) |
sys/riscv/riscv/pmap.c | ||
---|---|---|
360 | I was wondering about that too, as I'm starting to work on superpage support. We'll probably eventually have a use for an is_writable predicate for superpage mappings (ditto for the other predicates below). One wrinkle, though, is that we use distinct types (pd_entry_t vs. pt_entry_t). I'm not sure if that indicates that we should instead use a macro or just test bits inline. I lean somewhat towards the latter, since the flag names are pretty clear. |
sys/riscv/riscv/pmap.c | ||
---|---|---|
360 | I think it is also probably readable to just test bits inline. What does amd64 do? That's probably the best pmap to be copying from. |
sys/riscv/riscv/pmap.c | ||
---|---|---|
360 | amd64 is hamstrung by the fact that the bit definitions vary depending on the pmap type, so it's more or less forced to look up the definition once and then use inline tests. I'll think about it a bit more, but I'm inclined to just get rid of these predicates and inline everything. I'll upload the diff here once that's done. |
Might be convert namei reference in the similar way:
file system path lookups
.Pq Xr namei 9 ,