RFC Another go at ktime_get_raw_fast_ns()
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest4 patches 5 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | time: Rename timekeeper::tkr to timekeeper::tkr_monoarch/ arch/ arch/ +4 more | +126 | 0 replies | |
| 2/4 | time: Add timerkeeper::tkr_rawinclude/ kernel/ | +21 | 0 replies | |
| 3/4 | time: Parametrize all tk_fast_mono userskernel/ | +15 | 0 replies | |
| 4/4 | time: Introduce tk_fast_rawkernel/ | +13 | 0 replies |
Reviews trailers per patch
None of the 4 patches has a Reviewed-by or Acked-by of their own; the series has one for all of them.
| Patch | John Stultz |
|---|---|
| Series | A-b |
| 1/4 | |
| 2/4 | |
| 3/4 | |
| 4/4 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [RFC][PATCH 0/4] Another go at ktime_get_raw_fast_ns()
Hi John,
So yeah, I just didn't try hard enough it seems; how about this?
Also, I think we should double check that everything passed to tk_setup_internals(.clock) is either static storage or RCU-sched freed, because with the whole latch thing one CPUs (fast) access might still be in progress while the other is freeing the clock struct.
Not sure what the lifetime rules of struct clocksource are here.