OProfile

I like the addition of doc/CodingStyle. I have a couple comments about it:

There should be be some mention why we want to avoid inline functions, 
particularly in headers. The example I can think immediately is inline 
functions in headers make it impossible to compile with code 
optimization turned off. This is one of the drawbacks with the Linux kernel.

There should be some mention of indentation, tabs with each tab being 8 
column.


Would it be possible to have gindent the formatting, e.g. two blank 
lines between functions and indentation and the like? This would make 
life easier for the people that are getting their patch into the 
appropriate style. I know that the GDB people have picked a style that 
that the formatting can be enforced by a script. As a result, gdb has a 
consistent format and people reviewing patches spend time reviewing the 
semantics of the patch rather than the line spacing.

-Will

Re: doc/CodingStyle From: John Levon <levon@mo...> - 2003-01-20 19:28 On Mon, Jan 20, 2003 at 02:20:53PM -0500, William Cohen wrote: > There should be be some mention why we want to avoid inline functions, > particularly in headers. The example I can think immediately is inline > functions in headers make it impossible to compile with code > optimization turned off. This is one of the drawbacks with the Linux kernel. The main reason is that it generally tends to code bloat for no good reason. > There should be some mention of indentation, tabs with each tab being 8 > column. That's mentioned in Linus' coding doc which I refer to. > Would it be possible to have gindent the formatting, e.g. two blank > lines between functions and indentation and the like? This would make There is -bap, don't know if it's possible to get the effect of -2bap. indent will only be a partial solution anyway. regards john -- "Anyone who quotes Rusty in their sig is an idiot." - me

Re: doc/CodingStyle From: Richard Henderson <rth@tw...> - 2003-01-20 21:38 On Mon, Jan 20, 2003 at 02:20:53PM -0500, William Cohen wrote: > The example I can think immediately is inline > functions in headers make it impossible to compile with code > optimization turned off. This is false. > This is one of the drawbacks with the Linux kernel. No, this is the Linux kernel mis-using extern inline functions. In that they didn't provide the out-of-line fallback function required by the semantics of gcc's extern inline extension. r~

Re: doc/CodingStyle From: William Cohen <wcohen@nc...> - 2003-01-20 22:07 Richard Henderson wrote: > On Mon, Jan 20, 2003 at 02:20:53PM -0500, William Cohen wrote: > >>The example I can think immediately is inline >>functions in headers make it impossible to compile with code >>optimization turned off. > > > This is false. > > >>This is one of the drawbacks with the Linux kernel. > > > No, this is the Linux kernel mis-using extern inline functions. > In that they didn't provide the out-of-line fallback function > required by the semantics of gcc's extern inline extension. What is the correct way for the kernel code to use inline functions? Providing a duplicate function that isn't inline doesn't sound like a great idea? Use "__attribute__((always_inline))"? > > > r~ > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > oprofile-list mailing list > oprofile-list@... > https://lists.sourceforge.net/lists/listinfo/oprofile-list >

Re: doc/CodingStyle From: Richard Henderson <rth@tw...> - 2003-01-20 22:15 On Mon, Jan 20, 2003 at 05:07:35PM -0500, William Cohen wrote: > What is the correct way for the kernel code to use inline functions? > Providing a duplicate function that isn't inline doesn't sound like a > great idea? Use "__attribute__((always_inline))"? Or use static inline? Though, as John says, the vast majority of the cases don't warrent inline anyway. r~

609 messages have been excluded from this view by a project administrator.