On Fri, Jun 01, 2007 at 04:33:06PM -0400, Mathieu Desnoyers wrote: > * Andi Kleen ([EMAIL PROTECTED]) wrote: > > > Yes, but as you have probably understood, I want to have everything > > > embedded at the cond_call() site rather than polluting the rest of the > > > code with declarations. > > > > A cond call is essentially a fancy variable. And the Linux kernel > > is written in C and in C you declare variables before you use them. > > Also it would allow compile time checking against typos and > > allow removing some nasty hash table code. The proposal sounds like a > > clear winner to me. > > > > You could not declare in advance a structure that would contain pointers > to every load immediate instruction of the optimized cond_calls. Unless
To find them you just walk the sections. Changing cond call is a slow path operation. That is similar to how the smp lock switching works today. > I understand that if we limit ourselves to applications like the two > toy examples I proposed (enabling profiling and bug fixups), it could > make sense to try to declare a variable somewhere and later use it in > the body of functions (except the fact that it cannot work, due to > incapacity to declare pointers to each load immediate instruction, as > stated above). Even if it would work, the main purpose here is to > support the Linux Kernel Markers, where the goal is to provide the > ability to declare a marker within the body of a function without > requiring more hassle than a printk, but with less performance impact > than the latter. Also, we would not want the whole kernel to recompile > simply because someone chose to add one or two marker in his own driver > to extract some more information and had to add them to some globally > included header file. Sounds similar to config.h then when Kconfig keeps track of those dependencies for the CONFIG_*s and only recompiles what is needed. Perhaps this infrastructure could be reused. -Andi - 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/
