linux-kernel - Re: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Feb 2007 15:43:31 -0600
From:	Maynard Johnson <maynardj@...ibm.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	cbe-oss-dev@...abs.org, linuxppc-dev@...abs.org,
	linux-kernel@...r.kernel.org, oprofile-list@...ts.sourceforge.net,
	Carl Love <cel@...ibm.com>
Subject: Re: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated
 patch

Arnd Bergmann wrote:

> On Friday 16 February 2007 01:32, Maynard Johnson wrote:
> 
>>config OPROFILE_CELL
>>        bool "OProfile for Cell Broadband Engine"
>>        depends on OPROFILE && SPU_FS
>>        default y if ((SPU_FS = y && OPROFILE = y) || (SPU_FS = m && 
>>OPROFILE = m))
>>        help
>>          Profiling of Cell BE SPUs requires special support enabled
>>          by this option.  Both SPU_FS and OPROFILE options must be
>>          set 'y' or both be set 'm'.
>>=============
>>
>>Can anyone see a problem with any of this . . . or perhaps a suggestion 
>>of a better way?
> 
> 
> The text suggests it doesn't allow SPU_FS=y with OPROFILE=m, which I think
> should be allowed. 
Right, good catch.  I'll add another OR to the 'default y' and correct 
the text.

 > I also don't see any place in the code where you actually
> use CONFIG_OPROFILE_CELL.
As I mentioned, I will use CONFIG_OPROFILE_CELL in the 
arch/powerpc/oprofile/Makefile as follows:
      oprofile-$(CONFIG_OPROFILE_CELL) += op_model_cell.o \
               cell/spu_profiler.o cell/vma_map.o cell/spu_task_sync.o

> 
> Ideally, you should be able to have an oprofile_spu module that can be
> loaded after spufs.ko and oprofile.ko. In that case you only need
> 
> config OPROFILE_SPU
> 	depends on OPROFILE && SPU_FS
> 	default y
> 
> and it will automatically build oprofile_spu as a module if one of the two
> is a module and won't build it if one of them is disabled.
Hmmm . . . I guess that would entail splitting out the SPU-related stuff 
from op_model_cell.c into a new file.  Maybe more -- that's just what 
comes to mind right now.  Could be very tricky, and I wonder if it's 
worth the bother.
> 
> 	Arnd <><


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/