On Fri, 2018-12-07 at 21:46 +0100, Paolo Abeni wrote:

quoted

I wonder if we can declare the common case functions as 'weak' so that
the link failures don't happen when they're absent.

I experimented a previous version with alias. I avoided weak alias
usage, because I [mis?]understood not all compilers have a complete
support for them (e.g. clang).
Also, with weak ref, a coding error that is now discovered at build
time will result in worse performance at runtime, likely with some
uncommon configuration, possibly not as easily detected. I'm unsure
that would be better ?!?

I think everything supports weak linkage; we've been using it for
years.

quoted

Once we extend this past the network code, especially to file systems'
f_ops, I suspect we're going to want to use something like static keys
to patch the common cases at runtime — perhaps changing the f_ops
default according to what the root file system is, etc.

I'm sorry, I don't follow here. I think static keys can't be used for
the reported network case: we have different list elements each
contaning a different function pointer and we access/use
different ptr on a per packet basis.

Yes, the alternatives would be used to change the "likely" case.

We still do the "if (fn == default_fn) default_fn(); else (*fn)();"
part; or even the variant with two (or more) common cases. 

It's just that the value of 'default_fn' can be changed at runtime
(with patching like alternatives/static keys, since of course it has to
be a direct call).