OProfile

On Thu, Nov 11, 2004 at 01:23:33AM -0800, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm5/
>
> +oprofile-add-check_user_page_readable.patch
> +oprofile-arch-independent-code-for-stack-trace.patch
> +oprofile-i386-support-for-stack-trace-sampling.patch
> +oprofile-i386-support-for-stack-trace-sampling-fix.patch
> +oprofile-ia64-support-for-oprofile-stack-trace.patch
> +oprofile-update-alpha-for-api-changes.patch
> +oprofile-update-arm-for-api-changes.patch
> +oprofile-update-ppc-for-api-changes.patch
> +oprofile-update-parisc-for-api-changes.patch
> +oprofile-update-s390-for-api-changes.patch
> +oprofile-update-sh-for-api-changes.patch
> +oprofile-update-sparc64-for-api-changes.patch
> 
>  oprofile support for callgraph generation

Thanks, Andrew.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.

Re: 2.6.10-rc1-mm5 From: Andrew Morton <akpm@os...> - 2004-11-11 20:39 Greg Banks <gnb@...> wrote: > > On Thu, Nov 11, 2004 at 01:23:33AM -0800, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm5/ > > > > +oprofile-add-check_user_page_readable.patch > > +oprofile-arch-independent-code-for-stack-trace.patch > > +oprofile-i386-support-for-stack-trace-sampling.patch > > +oprofile-i386-support-for-stack-trace-sampling-fix.patch > > +oprofile-ia64-support-for-oprofile-stack-trace.patch > > +oprofile-update-alpha-for-api-changes.patch > > +oprofile-update-arm-for-api-changes.patch > > +oprofile-update-ppc-for-api-changes.patch > > +oprofile-update-parisc-for-api-changes.patch > > +oprofile-update-s390-for-api-changes.patch > > +oprofile-update-sh-for-api-changes.patch > > +oprofile-update-sparc64-for-api-changes.patch > > > > oprofile support for callgraph generation > > Thanks, Andrew. No probs. I took a closer look at the code and have decided that you guys aren't as insane as initial impressions indicate ;) oprofile code does seem to have a bit of an obsession with a) putting a space between the asterisk and the identifier when declaring pointers and b) putting extern decls in .c rather than in .h. But it's hardly unique in those things. Ho hum.

Re: 2.6.10-rc1-mm5 From: John Levon <levon@mo...> - 2004-11-11 21:17 On Thu, Nov 11, 2004 at 12:39:17PM -0800, Andrew Morton wrote: > No probs. I took a closer look at the code and have decided that you guys > aren't as insane as initial impressions indicate ;) We'll see... > oprofile code does seem to have a bit of an obsession with > > a) putting a space between the asterisk and the identifier when > declaring pointers and This is the style used in the rest of OProfile. I could corner you and bore you to death as to why I prefer it, but you'd rather I don't bother I think. It's also close enough to Linus style that it doesn't matter much I would say. > b) putting extern decls in .c rather than in .h. There was another offender beyond timer_init() ? regards john

Re: 2.6.10-rc1-mm5 From: Andrew Morton <akpm@os...> - 2004-11-11 21:25 John Levon <levon@...> wrote: > > On Thu, Nov 11, 2004 at 12:39:17PM -0800, Andrew Morton wrote: > > > No probs. I took a closer look at the code and have decided that you guys > > aren't as insane as initial impressions indicate ;) > > We'll see... > > > oprofile code does seem to have a bit of an obsession with > > > > a) putting a space between the asterisk and the identifier when > > declaring pointers and > > This is the style used in the rest of OProfile. I could corner you and > bore you to death as to why I prefer it, but you'd rather I don't bother > I think. It's also close enough to Linus style that it doesn't matter > much I would say. Such things seem gratuitous, and irk me. > > b) putting extern decls in .c rather than in .h. > > There was another offender beyond timer_init() ? arch/i386/oprofile/init.c and nmi_timer_init().

Re: 2.6.10-rc1-mm5 From: Albert Cahalan <albert@us...> - 2004-11-11 22:29 On Thu, 2004-11-11 at 16:16, John Levon wrote: > On Thu, Nov 11, 2004 at 12:39:17PM -0800, Andrew Morton wrote: > > oprofile code does seem to have a bit of an obsession with > > > > a) putting a space between the asterisk and the identifier when > > declaring pointers and > > This is the style used in the rest of OProfile. I could corner you and > bore you to death as to why I prefer it, but you'd rather I don't bother > I think. It's also close enough to Linus style that it doesn't matter > much I would say. That would be a fine argument... if you weren't such a stickler for your own style in the oprofile code. I'd rather everyone ignore this kind of thing, but if you're going to get obsessively picky about formatting and style in your own code, I think it's entirely fair to expect that you follow the Linux style down to the last byte.

Re: 2.6.10-rc1-mm5 From: Greg Banks <gnb@sg...> - 2004-11-12 00:11 On Thu, Nov 11, 2004 at 01:25:23PM -0800, Andrew Morton wrote: > John Levon <levon@...> wrote: > > > b) putting extern decls in .c rather than in .h. > > > > There was another offender beyond timer_init() ? > > arch/i386/oprofile/init.c and nmi_timer_init(). A quick perusal shows also extern int perfmon_init(struct oprofile_operations * ops); extern void perfmon_exit(void); extern int nmi_init(struct oprofile_operations * ops); extern void nmi_exit(void); extern int nmi_active; extern void x86_backtrace(struct pt_regs * const regs, unsigned int depth); extern void ia64_backtrace(struct pt_regs * const regs, unsigned int depth); There are trivially fixable. Andrew, do you want these given the same treatment as timer_init() ? Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI.

Re: 2.6.10-rc1-mm5 From: Andrew Morton <akpm@os...> - 2004-11-12 00:20 Greg Banks <gnb@...> wrote: > > extern int perfmon_init(struct oprofile_operations * ops); > extern void perfmon_exit(void); > extern int nmi_init(struct oprofile_operations * ops); > extern void nmi_exit(void); > extern int nmi_active; > extern void x86_backtrace(struct pt_regs * const regs, unsigned int depth); > extern void ia64_backtrace(struct pt_regs * const regs, unsigned int depth); > > There are trivially fixable. Andrew, do you want these given the > same treatment as timer_init() ? That would be nice, thanks.

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