Hi,
On Apr 3 2018 21:03, Takashi Iwai wrote:
It's better for this kind of code to be incline function in any header. In
general, new symbols increase maintenance cost of binary of kernel-related
stuffs. It's preferable to avoid the addition if possible, IMO.
I don't understand, functionally it's the same, there should not be any
increased maintenance either way. Please explain how this makes things
"harder"?
Hm, if so it might be my misunderstanding to reasons for typical usage
of inline functions in kernel source, sorry.
In my understanding, exported symbols are put into some sections of
ELF binary. Addition of new symbols increases size of the
section. Additionally, after linking vmlinux, kbuild scans built-in
symbols and make a file with entries of them. The addition increases
time of this step. Furthermore, at the end of building kernel, kmod is
called to generate some map files for exported symbols in loadable
module. In a view of distributors, these files are maintained by
binary packages of any type carefully because some incompatibilities
can be delivered such as version mismatch.
For these reasons, I think thing goes harder when people carelessly
add new symbols for functions with a few codes; e.g. accessing to a
member of structure, then simply check an return it. Actually I can
see some examples in upstreamed headers.
The advantage of inline function isn't about the maintenance cost.
It's mostly for performance, as well as the binary size reduction.
Actually, when a kernel live-patching comes into play, an inline
function is worse from the maintenance POV. Then we'd have to patch
every place that is expanded instead of a single place.
However, this doesn't discourage the use of inline function, either.
I'm OK for this view, and let me add it to my criteria for my daily
reviewing work. Thanks for sharing the view.
Overall, the performance is still the most important factor for major
cases. So I agree with that this particular case can be well inlined,
supposing that no complex code is planned to be added in future.
I agree with it as well. When developers add more complexity to content
of the inline function, then let them convert it to exported symbols.
Thanks
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
