* Adrian Bunk <[email protected]> wrote:
> My email was about things like Andi's example of the x86-64 vsyscall
> code where we really need inlining, and due to your proposed inline
> semantics change there might be breakages if an __always_inline is
> forgotten at a place where it was required.
we can have two types of breakages:
- stuff wont build if not always_inline. Really easy to find and fix.
- stuff wont work at all (e.g. vsyscalls) because they have some
unspecified reliance on gcc's code output. Such code Is Bad anyway,
and the breakage is still clear: the vsyscalls wont work at all, it's
quickly found, the appropriate always_inline is inserted, and the
incident is forgotten.
talking about 'safer' or 'risky' in this context is misleading, these
are very clear symptoms which are easy to fix.
[ If you didnt talk about this uninline patch in the "we have to wait
one year" comment then please clarify that - all that came through to
me was some vague "lets wait with this" message, and it wasnt clear
(to me) which patch it applied to and why. ]
> Your uninline patch might be simple, but the safe way would be Arjan's
> approach to start removing all the buggy inline's from .c files.
sure, that's another thing to do, but it's also clear that there's no
reason to force inlines in the -Os case.
There are 22,000+ inline functions in the kernel right now (inlined
about a 100,000 times), and we'd have to change _thousands_ of them.
They are causing an unjustified code bloat of somewhere around 20-30%.
(some of them are very much justified, especially in core kernel code)
to say it loud and clear again: our current way of handling inlines is
_FUNDAMENTALLY BROKEN_. To me this means that fundamental changes are
needed for the _mechanics_ and meaning of inlines. We default to 'always
inline' which has a current information to noise ratio of 1:10 perhaps.
My patch changes the mechanics and meaning of inlines, and pretty much
anything else but a change to the meaning of inlines will still result
in the same scenario occuring over and over again.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
