On Fri, 2018-12-07 at 21:46 +0100, Paolo Abeni wrote: > > 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. > > 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).
smime.p7s
Description: S/MIME cryptographic signature
