(2014/01/22 21:36), Christos Zoulas wrote: > On Jan 22, 11:00am, [email protected] (Ryota Ozaki) wrote: > -- Subject: Re: Porting DTrace to ARM > > | > 1. there seem to be some whitespace only changes > | > | Sorry for the messy code. Will fix. > > Not a problem :-) > | > | > 2. what's the STRONG_ALIAS to __ffssi2 about? > | > | This is needed to modload solaris. Without the fix > | I got the following error: > | # modload solaris > | kobj_checksyms, 880: [solaris]: linker error: symbol `__ffssi2' not found > | WARNING: module error: unable to affix module `solaris', error 8 > | modload: Exec format error > | > | This problem seems to be not dtrace specific. Other modules, > | e.g., nand, are also encountered the error in the case of > | evbarm/BEAGLEBONE. > | > | I want someone to confirm the problem on an evbarm/BEAGLEBONE > | machine (and other evbarm/arm machines). > | > | I think this fix should be a separate patch if the fix is > | correct. > > I think it is fine, I was just asking.
OK. I'm sending a patch via sendpr. > > | > 3. what about the deleted code in dtrace_debug.c > | > | The deletion is because of replacing dtrace_cmpset_long > | with atomic_cas_ulong. Please see the reply to 5. for > | more discussion. > > Ok, sounds good (and for 5) > > | > 4. I am torn about the cpuid -> cpu_id change. In my version of the > | > changes, I had fixed the arm code instead in sys/arch/arm. It was > | > used in very few places there. > | > | Sure. I changed cpuid -> cpu_id because I thought I should > | reduce the changes of the kernel core code. So if the change > | of the arm code is acceptable, I will do it in my next patch. > > I think it is; when I compiled dtrace for arm, there were only a handful > of places that cpuid was used. I would check with [email protected] though, > who I've CC:ed. OK. I'm changing so. A revised patch would be uploaded at gist in a couple of days. Thanks, ozaki-r > > Thanks again for all the work, > > christos >
