Re: Porting DTrace to ARM

[Ryota Ozaki <ozaki-r%NetBSD.org@localhost>]

On Thu, Mar 6, 2014 at 1:26 PM, Matt Thomas <matt%3am-software.com@localhost> 
wrote:
>
> On Mar 5, 2014, at 8:25 PM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>
>> On Thu, Mar 6, 2014 at 12:48 PM, Matt Thomas 
>> <matt%3am-software.com@localhost> wrote:
>>>
>>> On Mar 5, 2014, at 7:33 PM, Ryota Ozaki <ozaki-r%NetBSD.org@localhost> 
>>> wrote:
>>>
>>>> On Thu, Mar 6, 2014 at 1:39 AM, Matt Thomas 
>>>> <matt%3am-software.com@localhost> wrote:
>>>>>
>>>>> On Mar 5, 2014, at 3:12 AM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> 
>>>>> wrote:
>>>>>
>>>>>> - Replace cpu_id with cpuid in sys/arch/arm
>>>>>> - Can I commit the change?
>>>>>
>>>>> Why?  It's just churn for no reason I can see.
>>>>
>>>> The background is that cpu_id in sys/arch/arm conflicts with
>>>> the code in cddl and we have to change either one. I and christos
>>>> (he already replied in another mail) decided to change
>>>> sys/arch/arm, which seems less pain.
>>>
>>> The problem is that all the functions in cpufunc.h are cpu_xxx
>>> cpuid would be an outlier.
>>>
>>> I think a better solution might be to put a field for dtrace
>>> into cpu_data and just curcpu()->ci_dtraceinfo->foo
>>> to get to it instead have a parallel structure.
>>>
>>> You want to put a dtrace in mi_attach_cpu to initialize/allocate it.
>>
>> Sounds reasonable (except that it needs to modify cddl much though).
>> Can we do attach_cpu in a module?
>
> Too late for the most part.

# oh, mi_attach_cpu is correct. I found it now :)

Okay, so we need to have some code in src/sys. Hmm, big change
(for me). I can do it, but I don't know if it's ok or not.

Christos, how do you think?

  ozaki-r