Explain some basic expectations about architectures supported by FreeBSD, note about ILP32 and LP64.
Details
Details
- Reviewers
emaste imp - Group Reviewers
manpages - Commits
- rS317809: Provide introduction for the arch(7) manpage.
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| share/man/man7/arch.7 | ||
|---|---|---|
| 51 ↗ | (On Diff #28013) | In fact, I think that this is not that important to put exact list in arch(7). I reformulated this into more vague note specifying that it is possible to have either. Main point there I wanted to make is that address space available to usermode varies. |
| 102 ↗ | (On Diff #28013) | Only ARMv8 has optional 32bit mode, other architectures are dual-mode always, AFAIK. Please correct me. I mentioned AArch32 as a prerequisite. |
Comment Actions
Mention two-complement.
AArch32 support is required for 32bit (but we do not).
Make list of arches where K/U AS different more vague.
| share/man/man7/arch.7 | ||
|---|---|---|
| 102 ↗ | (On Diff #28013) | Correct. VAX is the only other example I can think where some CPUs had the new mode, while others had both. That's not relevant here though. |
| share/man/man7/arch.7 | ||
|---|---|---|
| 42–44 ↗ | (On Diff #28028) | @brooks might have something to say about this :-) It's useful (and correct) to accurately document this state of affairs as it exists today, although maybe a very brief comment about changes coming up? |
| 56 ↗ | (On Diff #28028) | *the* kernel uses *a* separate address space |
| 57 ↗ | (On Diff #28028) | Maybe "kernel and user share a single address space"? |
| 60 ↗ | (On Diff #28028) | user main thread? |
| 63 ↗ | (On Diff #28028) | Maybe "All FreeBSD architectures use some variant of" |
| share/man/man7/arch.7 | ||
|---|---|---|
| 42–44 ↗ | (On Diff #28028) | Could you propose the wording ? I believe that chery is neither ILP32 nor LP64, so more editing will be required at that time. IMO for now it is enough to reflect the present state. |
| share/man/man7/arch.7 | ||
|---|---|---|
| 49 ↗ | (On Diff #28033) | Maybe something like: In order to maximize compatibility with future pointer integrity mechanisms, manipulations of pointers as integers should be performed via .Vt uintptr_t or .Vt intptr_t and no other types. In particular, .Vt long and .Vt ptrdiff_t should be avoided. |
Comment Actions
I think this is fine with a few articles as pointed out inline; we can always refine it further later on.
| share/man/man7/arch.7 | ||
|---|---|---|
| 44 ↗ | (On Diff #28037) | probably variables, *and* uintptr_t and size_t types are... |
| 70 ↗ | (On Diff #28037) | Channeling wblock, avoid comma splace: "single address space. The kernel is located at the highest addresses." |
| 72 ↗ | (On Diff #28037) | probably "the main user mode thread's stack" |
| 73 ↗ | (On Diff #28037) | *the* highest |
| 75 ↗ | (On Diff #28037) | of *the* ELF |
| 101 ↗ | (On Diff #28037) | comma splice, |
| 103 ↗ | (On Diff #28037) | where *the* native |
| 119 ↗ | (On Diff #28037) | *the* CPU |