Re: Porting DTrace to ARM

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

percpu(9) might help?

On Thu, Mar 6, 2014 at 1:55 PM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> 
wrote:
> 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