Messages in this thread | | | Date | Wed, 23 May 2007 19:16:24 +0530 | From | "Satyam Sharma" <> | Subject | Re: any value to "NORET_TYPE" macro? |
| |
Hi Robert,
On 5/23/07, Robert P. J. Day <rpjday@mindspring.com> wrote: > On Wed, 23 May 2007, Satyam Sharma wrote: > > > On 5/23/07, Krzysztof Halasa <khc@pm.waw.pl> wrote: > > > "Robert P. J. Day" <rpjday@mindspring.com> writes: > > > > > > > that may be but, as i suggested earlier, that would get into > > > > guessing what those developers were thinking, and i just didn't > > > > want to go there. > > > > > > No guessing, I just checked it (though a second check wouldn't do > > > any harm). > > > > > > > the simple version of the patch is now in andrew's tree, and > > > > i'll worry about the harder stuff next time. > > > > > > The "next time" would be much harder as there would be no key for > > > searching for these functions. > > > > Krzysztof's absolutely right ... we don't want to lose the > > NORET_TYPE annotations on all these functions before we switch them > > to ATTRIB_NORET. And yes, _all_ of these NORET_TYPE's do want to be > > ATTRIB_NORET (except for those that are double-annotated, for those > > we can just get rid of the NORET_TYPE macro). > > ok, i'll go back and take another look at this.
Actually there's another thing :-) The __attribute__((xxx)) must go with the function _declarations_ (and not the implementations/definitions). I noticed after my previous mail that most of the double annotations are actually in the case of the _declarations_ of these non-returning functions, whereas most of the single-occurrences of NORET_TYPE were in the function definitions, which means your patch that simply got rid of NORET_TYPE actually ended up doing exactly the right thing that we wanted :-)
The unfortunate / ugly part, however, is that there are few cases where the above doesn't hold true ([1] NORET_TYPE without ATTRIB_NORET in function declaration e.g. in include/asm-mips/ptrace.h -- this must become ATTRIB_NORET, and [2] ATTRIB_NORET either alone or with NORET_TYPE in function definitions e.g. arch/mips/kernel/traps.c -- these can be eliminated entirely, and [3] NORET_AND occurrences where we don't really want ATTRIB_NORET anymore, so just removing NORET_TYPE would be right).
So this might not really be a simple patch anymore, and because the benefit of ATTRIB_NORET is only miniscule, so you can ignore my previous mail if you want :-)
Thanks, Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |