On Mar 6, 1:55pm, [email protected] (Ryota Ozaki) wrote: -- Subject: Re: Porting DTrace to ARM
| On Thu, Mar 6, 2014 at 1:26 PM, Matt Thomas <[email protected]> wrote: | > | > On Mar 5, 2014, at 8:25 PM, Ryota Ozaki <[email protected]> wrote: | > | >> On Thu, Mar 6, 2014 at 12:48 PM, Matt Thomas <[email protected]> wrote: | >>> | >>> On Mar 5, 2014, at 7:33 PM, Ryota Ozaki <[email protected]> wrote: | >>> | >>>> On Thu, Mar 6, 2014 at 1:39 AM, Matt Thomas <[email protected]> wrote: | >>>>> | >>>>> On Mar 5, 2014, at 3:12 AM, Ryota Ozaki <[email protected]> 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? It is probably easier to change cddl at this point or make cpu_id() an inline. christos
