(2014/01/22 21:36), Christos Zoulas wrote:
On Jan 22, 11:00am, ozaki-r%iij.ad.jp@localhost (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 matt%netbsd.org@localhost
though,
who I've CC:ed.
OK. I'm changing so.
A revised patch would be uploaded at gist in a couple of days.