Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 22 Mar 2023 11:45:18 -0700 | From | Josh Poimboeuf <> | Subject | Re: [PATCH v2 11/11] static_call: Remove DEFINE_STATIC_CALL_RET0() |
| |
On Wed, Mar 22, 2023 at 04:15:32PM +0100, Peter Zijlstra wrote: > On Tue, Mar 21, 2023 at 09:00:17PM -0700, Josh Poimboeuf wrote: > > NULL and RET0 static calls are both slightly different ways of nopping a > > static call. A not-insignificant amount of code and complexity is spent > > maintaining them separately. It's also somewhat tricky for the user who > > has to try to remember to use the correct one for the given function > > type. > > Well, I have very little sympathy for that argument. The return type > should be a big frigging clue. > > > Simplify things all around by just combining them, such that NULL static > > calls always return 0. > > > > While it doesn't necessarily make sense for void-return functions to > > return 0, it's pretty much harmless. The return value register is > > already callee-clobbered, and an extra "xor %eax, %eax" shouldn't affect > > performance (knock on wood). > > Urgh.. OTOH I do like the lines removes.
So this patch is more of an RFC than the others. I'm not fully convinced myself, but I very much liked the removed lines and simpler interface.
> > This "do nothing return 0" default should work for the vast majority of > > NULL cases. Otherwise it can be easily overridden with a user-specified > > function which panics or returns 0xdeadbeef or does whatever one wants. > > > > This simplifies the static call code and also tends to help simplify > > users' code as well. > > Can we at least keep the DEFINE_STATIC_CALL_RET0() and > __static_call_return0 as aliases? It reads really daft to use _NULL or > __static_call_nop for non-void functions.
I disagree, to me NULL means "nop the function (including any return value)". Nice and easy.
Keeping those other ret0 defines around would negate some of the cool deletions.
-- Josh
| ![\](/images/icornerr.gif) |