* 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 I'm wrong, this idea just can't be implemented in C. > > Also, if we have the same cond_calls in different modules, in which > > module shall it be defined ? > > In one of them. Like all other variables in C. > 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. Therefore, due to the use of cond_calls within markers, I strongly prefer the dynamic implementation I proposed to implementations requiring additional variable declaration and frequent header changes. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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/
