From: Philippe E. <ph...@wa...> - 2002-09-03 16:12:44
|
John Levon wrote: >On Tue, Sep 03, 2002 at 10:30:04AM -0400, Will Cohen wrote: > > ... >>I would like to also move op_rtc.c out of the module directory or >>atleast not compiled at all times. Some targets such as the ia64 do not >>support RTC in this manner. I moved it into modules/x86. Maybe the more >>appropriate manner is to have a module/rtc directory used for machines >>with unsupported performance monitoring hardware, have the op_rtc.c file >>in there, and have symbolic link from what ever machine specific >>directory into there, so we don't have multiple copies of the file. >> >> > >I'm fine with moving it into x86/ for now. We should also change it so >that the fallback-to-rtc logic is in x86/ too, so you don't need that >fake rtc code in ia64. > I prefer the Will way directly rtc/rtc.c rtc/no_rtc.c and select at configure the right filename, most af architecture are RTC capable and after the ia64 port the only needs to support new arch is to provide the syscall tracking. >>There have been some changes to help in the regard, but I don't think >>there has been really a way to test this on x86 machines. From what I >>have seen on the x86 machines the first entry in mmap list is the >>executable, so there isn't much difference between the before and after. >>On the ia64 machine I am using it definitely does not order the mmap >>entries, so things associating shared library samples with an executable >>oprofile gets wrong. >> >> > >Apparently /dev/mem is the first mapping with some X processes (not my >machine which is why I made the error in the first case). Have you >tested current CVS without your change here ? If it's still broken >hopefully Phil can find out what's still going wrong. > yeps I got this problem on x86 for XFree86, I think the current cvs should handle this case for ia64. regards, Phil |