Page MenuHomeFreeBSD

cpu_machdep.9: New manpage describing the semantics of several cpu_*
ClosedPublic

Authored by jhb on Dec 10 2024, 7:46 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Jan 6, 2:40 PM
Unknown Object (File)
Mon, Jan 6, 2:19 PM
Unknown Object (File)
Mon, Jan 6, 10:34 AM
Unknown Object (File)
Mon, Jan 6, 9:23 AM
Unknown Object (File)
Mon, Jan 6, 6:44 AM
Unknown Object (File)
Mon, Jan 6, 5:20 AM
Unknown Object (File)
Mon, Jan 6, 4:18 AM
Unknown Object (File)
Fri, Jan 3, 10:42 PM
Subscribers

Details

Summary

This page is not exhaustive but covers all of the MD interface
functions currently declared in <sys/proc.h>.

Requested by: kib
Sponsored by: AFRL, DARPA

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 61289
Build 58173: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Dec 10 2024, 7:46 PM
sys/sys/proc.h
1148 ↗(On Diff #147789)

Initially I sorted these alphabetically, but I ended up growing them by functionality a bit: process events (exec/fork/exit), user thread creation, syscall argument handling, cpu_idle, cpu_proccontrol, cpu_switch/throw, cpu_sync_core, then the thread object lifecycle. I think we also have some other cpu_* functions in other headers? A few of these have callouts in the implementations (e.g. cpu_fork tends to have a similar comment in every vm_machdep.c). I haven't removed those. Possibly I should as the goal is to centralize the comments?

1240 ↗(On Diff #147789)

Not sure why the whitespace varies here.

sys/sys/proc.h
1240 ↗(On Diff #147789)

It doesn't in the source, must be a weird phab issue.

I feel that the better place for this stuff would be cpu_machdep(9) rather then comments in the header.

sys/sys/proc.h
1154 ↗(On Diff #147789)
1156 ↗(On Diff #147789)
1167 ↗(On Diff #147789)
1187 ↗(On Diff #147789)
1215 ↗(On Diff #147789)
1220 ↗(On Diff #147789)
1251 ↗(On Diff #147789)
1254 ↗(On Diff #147789)

Not sure how to formulate it, but when the function returns, it returns to the caller. I.e., it returns twice, immediately in the context of the thread switched to, and then in the context of the calling thread once returned to CPU.

I'm fine with adding a manpage instead. There are other cpu_* functions in other headers that could be added then. I'll take a stab at doing that instead, but probably just starting with these functions.

jhb marked an inline comment as done.Fri, Dec 20, 7:04 PM
jhb added inline comments.
sys/sys/proc.h
1167 ↗(On Diff #147789)

The stack is copied by COWing the pages, but the user registers are certainly copied.

1251 ↗(On Diff #147789)

Hmm, it's not always kernel registers. User registers that aren't saved in the trapframe but saved in the PCB are also swapped here.

1254 ↗(On Diff #147789)

Yes, I'm not sure how to say it either. It's quite the same as "returns twice" the way setjmp is, it's more a matter of two different ways of looking at timelines. From a CPU-centric timeline, the function "returns" into the new thread (but not if it is a newborn thread). From a thread-centric timeline, the the function returns when the thread resumes execution.

jhb retitled this revision from proc.h: Document the semantics of the MD cpu_* interface to cpu_machdep.9: New manpage describing the semantics of several cpu_*.Fri, Dec 20, 7:27 PM
jhb edited the summary of this revision. (Show Details)
sys/sys/proc.h
1167 ↗(On Diff #147789)

s/stack/stack pointer/

share/man/man9/cpu_machdep.9
35
98
185
282

May be, directly write there what you described as return from the PoV of current thread, and from the PoV of CPU.

303
312
327
330
jhb marked 4 inline comments as done.Thu, Jan 2, 5:23 PM
jhb added inline comments.
share/man/man9/cpu_machdep.9
282

I've tried to add something. The thought I had a week or so ago was to describe the caller's experience (what to think when you are in mi_switch() for example) vs the implementer's experience (how to think about it when working on an implementation of cpu_switch itself.

303

Hmmm, I think OS thread is perhaps not clear. The distinction I'm aiming to make here is between kernel threads (with a kernel stack, and a kernel-visible object) vs user-space threads as some language runtimes may still employ some version of green threads or coroutines or something to multiplex multiple user-space threads onto a single kernel thread. One could argue that an OS thread might mean the user threads provided by an OS thread library (like libpthread), or at least I feel that the term is ambiguous.

kib added inline comments.
share/man/man9/cpu_machdep.9
273

It is important to note that after updating td_lock, the kernel stack of the old must not be accessed by the current CPU.

285

or accessing the new thread stack.

This revision is now accepted and ready to land.Fri, Jan 3, 11:57 AM
jhb marked 4 inline comments as done.Fri, Jan 3, 4:02 PM