On Jan 22, 11:00am, ozak...@iij.ad.jp (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. | > 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 m...@netbsd.org though, who I've CC:ed. Thanks again for all the work, christos