Re: Porting DTrace to ARM

2014-03-23 Thread Ryota Ozaki
FYI http://www.netbsd.org/~ozaki-r/pub/AsiaBSDCon2014-WIP-ozaki-r.pdf This is my slides about this work, which was presented in WIP session of AsiaBSDCon 2014 last week. Regards, ozaki-r On Mon, Mar 17, 2014 at 8:02 PM, Ryota Ozaki ozak...@netbsd.org wrote: I will commit the patch during

Re: Porting DTrace to ARM

2014-03-17 Thread Ryota Ozaki
I will commit the patch during AsiaBSDCon 2014 if there is no objection :) I did it. So you can try DTrace on ARM now! You can run some commands and scripts described in http://wiki.netbsd.org/tutorials/how_to_enable_and_run_dtrace/ . Beaglebone (Black) is a recommended machine for it.

Re: Porting DTrace to ARM

2014-03-14 Thread Ryota Ozaki
On Mon, Mar 10, 2014 at 5:04 PM, Ryota Ozaki ozak...@netbsd.org wrote: Hi, I've updated my patch. https://gist.github.com/ozaki-r/8535846 http://www.netbsd.org/~ozaki-r/dtrace-arm.patch The patch now consists of a few files: $ diffstat dtrace-arm.patch

Re: Porting DTrace to ARM

2014-03-10 Thread Ryota Ozaki
Hi, I've updated my patch. https://gist.github.com/ozaki-r/8535846 http://www.netbsd.org/~ozaki-r/dtrace-arm.patch The patch now consists of a few files: $ diffstat dtrace-arm.patch external/cddl/osnet/dev/dtrace/arm/dtrace_asm.S | 13 external/cddl/osnet/dev/dtrace/arm/dtrace_isa.c |

Re: Porting DTrace to ARM

2014-03-07 Thread Ryota Ozaki
Hi Matt, So my patch for sys/arch/arm is now rather small than so far (just two files); it's minimum code for the core part to run DTrace on ARM. Can you please check it? The patch for sys/arch/arm is http://www.netbsd.org/~ozaki-r/dtrace-arm-sys.patch The full patch is available at the usual

Re: Porting DTrace to ARM

2014-03-07 Thread Matt Thomas
On Mar 7, 2014, at 2:27 AM, Ryota Ozaki ozak...@netbsd.org wrote: Hi Matt, So my patch for sys/arch/arm is now rather small than so far (just two files); it's minimum code for the core part to run DTrace on ARM. Can you please check it? The patch for sys/arch/arm is

Re: Porting DTrace to ARM

2014-03-06 Thread David Laight
On Thu, Mar 06, 2014 at 03:34:18PM +0900, Ryota Ozaki wrote: On Thu, Mar 6, 2014 at 2:21 PM, Masao Uebayashi uebay...@gmail.com wrote: Ah. I misread that schedstate_percpu uses percpu(9)'s fast path, which doesn't exist... Anyway if it's assumed that cpu is not attached at run-time,

Re: Porting DTrace to ARM

2014-03-06 Thread Christos Zoulas
On Mar 6, 1:25pm, ozak...@netbsd.org (Ryota Ozaki) wrote: -- Subject: Re: Porting DTrace to ARM | The problem is that all the functions in cpufunc.h are cpu_xxx | cpuid would be an outlier. change it to static inline? christos

Re: Porting DTrace to ARM

2014-03-06 Thread Christos Zoulas
On Mar 6, 1:55pm, ozak...@netbsd.org (Ryota Ozaki) wrote: -- Subject: Re: Porting DTrace to ARM | On Thu, Mar 6, 2014 at 1:26 PM, Matt Thomas m...@3am-software.com wrote: | | On Mar 5, 2014, at 8:25 PM, Ryota Ozaki ozak...@netbsd.org wrote: | | On Thu, Mar 6, 2014 at 12:48 PM, Matt Thomas m

Re: Porting DTrace to ARM

2014-03-06 Thread Ryota Ozaki
On Thu, Mar 6, 2014 at 3:50 PM, Masao Uebayashi uebay...@gmail.com wrote: Well, more type is better. :) See [1]. My question was more like, what happens if CPU can be attached at run-time in the future? Per-CPU initialization operations have to be remembered somewhere. There is no concern

Re: Porting DTrace to ARM

2014-03-06 Thread Ryota Ozaki
On Thu, Mar 6, 2014 at 5:32 PM, David Laight da...@l8s.co.uk wrote: On Thu, Mar 06, 2014 at 03:34:18PM +0900, Ryota Ozaki wrote: On Thu, Mar 6, 2014 at 2:21 PM, Masao Uebayashi uebay...@gmail.com wrote: Ah. I misread that schedstate_percpu uses percpu(9)'s fast path, which doesn't exist...

Re: Porting DTrace to ARM

2014-03-06 Thread Ryota Ozaki
On Thu, Mar 6, 2014 at 10:46 PM, Christos Zoulas chris...@zoulas.com wrote: On Mar 6, 1:55pm, ozak...@netbsd.org (Ryota Ozaki) wrote: -- Subject: Re: Porting DTrace to ARM | On Thu, Mar 6, 2014 at 1:26 PM, Matt Thomas m...@3am-software.com wrote: | | On Mar 5, 2014, at 8:25 PM, Ryota

Re: Porting DTrace to ARM

2014-03-05 Thread Ryota Ozaki
Hi, So I've updated my patch: https://gist.github.com/ozaki-r/8535846 The new patch dropped committed changes, followed KNF (hopefully) and did some tweaks. At this point, what I would like to get feedbacks are some changes under sys/arch/arm: - Replace cpu_id with cpuid in sys/arch/arm -

Re: Porting DTrace to ARM

2014-03-05 Thread Matt Thomas
On Mar 5, 2014, at 3:12 AM, Ryota Ozaki ozak...@netbsd.org 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. - Move INKERNEL and FR_* macros from arm/arm/db_trace.c to arm/include/db_machdep.h to refer them in

Re: Porting DTrace to ARM

2014-03-05 Thread Ryota Ozaki
On Thu, Mar 6, 2014 at 12:48 PM, Matt Thomas m...@3am-software.com wrote: On Mar 5, 2014, at 7:33 PM, Ryota Ozaki ozak...@netbsd.org wrote: On Thu, Mar 6, 2014 at 1:39 AM, Matt Thomas m...@3am-software.com wrote: On Mar 5, 2014, at 3:12 AM, Ryota Ozaki ozak...@netbsd.org wrote: - Replace

Re: Porting DTrace to ARM

2014-03-05 Thread Masao Uebayashi
Ah. I misread that schedstate_percpu uses percpu(9)'s fast path, which doesn't exist... Anyway if it's assumed that cpu is not attached at run-time, assigning struct cpu_data::void *cpu_dtraceinfo at module attachment would be just fine. On Thu, Mar 6, 2014 at 2:08 PM, Matt Thomas

Re: Porting DTrace to ARM

2014-03-05 Thread Ryota Ozaki
On Thu, Mar 6, 2014 at 2:21 PM, Masao Uebayashi uebay...@gmail.com wrote: Ah. I misread that schedstate_percpu uses percpu(9)'s fast path, which doesn't exist... Anyway if it's assumed that cpu is not attached at run-time, assigning struct cpu_data::void *cpu_dtraceinfo at module attachment

Re: Porting DTrace to ARM

2014-03-05 Thread Masao Uebayashi
Well, more type is better. :) See [1]. My question was more like, what happens if CPU can be attached at run-time in the future? Per-CPU initialization operations have to be remembered somewhere. [1] http://mail-index.netbsd.org/tech-kern/2014/03/03/msg016699.html On Thu, Mar 6, 2014 at 3:34

Re: Porting DTrace to ARM

2014-02-03 Thread Ryota Ozaki
(2014/01/27 19:57), Ryota Ozaki wrote: (2014/01/27 14:43), Ryota Ozaki wrote: Hi Matt, Thank you very much for your kind reviewing. (2014/01/24 23:03), Matt Thomas wrote: On Jan 24, 2014, at 2:34 AM, Ryota Ozaki ozak...@iij.ad.jp wrote: Updated as I planned, there is no curious update

Re: Porting DTrace to ARM

2014-01-27 Thread Ryota Ozaki
(2014/01/27 14:43), Ryota Ozaki wrote: Hi Matt, Thank you very much for your kind reviewing. (2014/01/24 23:03), Matt Thomas wrote: On Jan 24, 2014, at 2:34 AM, Ryota Ozaki ozak...@iij.ad.jp wrote: Updated as I planned, there is no curious update though. Use of curcpu() or cpu_number()

Re: Porting DTrace to ARM

2014-01-26 Thread Ryota Ozaki
Hi Matt, Thank you very much for your kind reviewing. (2014/01/24 23:03), Matt Thomas wrote: On Jan 24, 2014, at 2:34 AM, Ryota Ozaki ozak...@iij.ad.jp wrote: Updated as I planned, there is no curious update though. Use of curcpu() or cpu_number() without having done kpreempt_disable() is

Re: Porting DTrace to ARM

2014-01-24 Thread Ryota Ozaki
(2014/01/23 20:15), Ryota Ozaki wrote: (2014/01/22 21:36), Christos Zoulas wrote: 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

Porting DTrace to ARM

2014-01-20 Thread Ryota Ozaki
Hi, I'm working on porting DTrace to ARM. The patch (*) is my WIP product on the work. It's not still mature but it works anyway in some cases. (*) https://gist.github.com/ozaki-r/8535846 I'm sending the patch because I would like to ask comments and suggestions whether I'm going to the right