vm: Convert vm_map_clip_end from a macro to a regular inline function

[cem]

Summary

No functional change.

[markj]

sys/vm/vm_map.c

2462 ↗

(On Diff #73142)

Why not do the same for vm_map_clip_start()?

Do we even need a separate _vm_map_clip_end()?

[cem]

sys/vm/vm_map.c

2462 ↗

(On Diff #73142)

start: I just didn't have a reason to modify vm_map_clip_start. If it also sometimes allocates memory, it's worth doing something similar. The rationale for this change is exclusively D25283 ; this was just done separately to highlight the functional change in the child revision.

Do we even need the wrapper? I don't know. I assume the idea of the macro was that it was more equivalent to __always_inline rather than plain inline, and that the longer function might not always be inlined. We could use __always_inline over inline here. I don't know if compiler heuristics result in the wrapped function being inlined or not. Maybe _vm_map_clip_end used to be in a separate CU, so it couldn't be inlined from the header, while the macro could? I don't know the history of this code very well.

[markj]

sys/vm/vm_map.c

2462 ↗

(On Diff #73142)

Please modify vm_map_clip_start() to avoid making them inconsistent. It can also allocate an entry. vm_map_clip_start() and _end() do pretty much the same thing, they just operate on different ends of a VA range.

I think the wrapper made more sense before recent refactorings. If you look at e.g., stable/11, _vm_map_clip_start()/end() were much longer. Doug has refactored them since then. It should be fine to just merge them.

[cem]

sys/vm/vm_map.c

2462 ↗

(On Diff #73142)

Sounds good to me.

[cem]

Unwrap both vm_map_clip_{start,end}

[cem]

Correct parameter names

[cem]

Upload the right diff...

[dougm]

sys/vm/vm_map.c

2390 ↗

(On Diff #73185)

Drop the underscore, or use "%s" and func.

2441 ↗

(On Diff #73185)

Drop the underscore, or just use %s and func.

[cem]

Fix func names in KASSERT.