On Thu, 5 Jan 2006, Linus Torvalds wrote:
>
> That way the "profile data" actually follows the source code, and is thus
> actually relevant to an open-source project. Because we do _not_ start
> having specially optimized binaries. That's against the whole point of
> being open source and trying to get users to get more deeply involved with
> the project.
Btw, having annotations obviously works, although it equally obviously
will limit the scope of this kind of profile data. You won't get the same
kind of granularity, and you'd only do the annotations for cases that end
up being very clear-cut. But having an automated feedback cycle for adding
(and removing!) annotations should make it pretty maintainable in the long
run, although the initial annotations migh only end up being for really
core code.
There's a few papers around that claim that programmers are often very
wrong when they estimate probabilities for different code-paths, and that
you absolutely need automation to get it right. I believe them. But the
fact that you need automation doesn't automatically mean that you should
feed the compiler a profile-data-blob.
You can definitely automate this on a source level too, the same way
sparse annotations can help find user access problems.
There's a nice secondary advantage to source code annotations that are
actively checked: they focus the programmers themselves on the issue. One
of the biggest advantages (in my opinion) of the "struct xyzzy __user *"
annotations has actually been that it's much more immediately clear to the
kernel programmer that it's a user pointer. Many of the bugs we had were
just the stupid unnecessary ones because it wasn't always obvious.
The same is likely true of rare functions etc. A function that is marked
"rare" as a hint to the compiler to put it into another segment (and
perhaps optimize more aggressively for size etc rather than performance)
is also a big hint to a programmer that he shouldn't care. On the other
hand, if some branch is marked as "always()", that also tells the
programmer something real.
So explicit source hints may be more work, but they have tons of
advantages. Ranging from repeatability and distribution to just the
programmer being aware of them.
In other projects, maybe people don't care as much about the programmer
being aware of what's going on - garbage collection etc silent automation
is all wonderful. In the kernel, I'd rather have people be aware of what
happens.
Linus
-
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]
