Maynard Johnson wrote:
> David Smith wrote:
>> Maynard Johnson wrote:
>>> Hello,
>>> I recently pulled down the systemtap src onto a Fedora 10 system and 
>>> tried to use the itrace
>>> probe point.  The resulting kernel module failed to compile because
>> the runtime/itrace.c file
>>> had not been updated to reflect the recent utrace interface changes.
>> This problem had not
>>> been caught because the itrace test is currently disabled (since it
>> fails on x86_64).
>>
>> I looked at your changes a bit.  In remove_usr_itrace_info(), you
>> probably need to ignore EALREADY (which means the DEATH callback has
>> already begun so there is no point in detaching).
>>
>> The changes look reasonable, but with a bit more effort you should be
>> able to support both the original utrace interface (for systems like
>> RHEL5) and the new utrace interface simultaneously.  The task_finder
>> layer does this now - look for '#ifdef UTRACE_ORIG_VERSION' sections and
>> look at runtime/utrace_compatibility.h.  Basically you write to the new
>> interface and use the defines and wrappers in
>> runtime/utrace_compatibility.h to make the original utrace interface
>> look like the new interface.
>>
>> It is possible you might need to add additional defines to
>> runtime/utrace_compatibility.h since the itrace code uses parts of
>> utrace that the task_finder layer doesn't use.
>>
>> Let me know if you need help with this or additional information.
> Thanks for the feedback.  The revised patch I'm attaching here contains 
> two changes compared to the original:  it ignores EALREADY in 
> remove_usr_itrace_info(); and I've added a private version of 
> 'access_process_vm' (as discussed on a separate posting thread).
> 
> Other issues I will continue to work on are:
>     - itrace test fails on x86_64
>     - add backward support for older utrace interface
> 
> Frank had granted me write access to the SystemTap repository a few 
> months ago, so I can commit this when I get approval.
It would help if I attached the patch . . . :-/

-Maynard

> 
> Thanks.
> -Maynard
>>
>