Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
- KRYPTIVA PACKAGED MESSAGE - PACKAGING TYPE: SIGNED Mathieu Desnoyers wrote: > The problem with your proposal, I guess, is that people will have to add a supplementary parameter to the macro. > > It is not uncommon to have two slightly versions of macros/functions in the kernel (preempt_enable()/preempt_enable_no_resched(), or macros starting with underscores). Normally, the underscore states that the macro does not do the proper locking itself (this is not our case). Therefore, I would suggest using a name that suggests against what the macro is protected. For instance, a marker > pointing to the generic version is only needed to protect against the debug trap handler and should only be used on x86 and x86_64. I can see your point, to a degree. The difference here is that the variants you mention are actually macros that do something, they aren't stubs for code. IOW, you actually know what's happening underneath a foo() vs. _foo() by its name only. Maybe this applies the same to markers, I don't know. But maybe we want to make it easy for those looking at markers that there's a master kill switch somewhere that all markers go through and through which they can all be disabled very simply (say by using a "#if 0"). While different names *may* be doing that, a same name *does* that. But I don't feel too strongly either way, it's really up to those who maintaining the code to say. Karim - KRYPTIVA SIGNED MESSAGE - This email claims to have been packaged by Kryptiva. To process this email and authenticate its origin, get the free plugin from: http://www.kryptiva.com/downloads - KRYPTIVA SIGNATURE START - AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2 +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFB0lithGcxNZYBHaLDONjp6eo/LoBwAUpXC6F2jf nElq3fnZQpGW97Fk/2QRABgAAABOIEXcvqAADJ5wAB4TAAQAggP/ RQ/W0H9H9bhrZyC67an//DbWC4D38PgLoeMG6Tjvx7jWTpEh79DeQ/+sbb9aYZvbwYwtaVaJ VuPEiRnPZX0mqnOFm+GDzE9jB6202lR0Nzczh1WCifbrrXI7CSEjOwI3ve0jcCoGxTEzZRYj LGxuubV8Hh5HU12zi3Mxgdz031Y= - KRYPTIVA SIGNATURE END - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
* Karim Yaghmour ([EMAIL PROTECTED]) wrote: > - KRYPTIVA PACKAGED MESSAGE - > PACKAGING TYPE: SIGNED > > Hello Mathieu, > > Mathieu Desnoyers wrote: > > Yes, that was indeed the first way I implemented it, as a "disable" > option. One of the main thing we have to figure out before I modify this is > if we want to have the generic version of markers available in a "forced" > manner at the marker site with the GEN_MARK macro instead of the MARK macro > (this is the actual implementation). It has proven to be useful to > instrument lockdep.c irq > > enable/disable tracing functions. The reason why is because they are > called just before the trap handler returns and I need it to do XMC on x86 > and x86_64. It would therefore cause a recursive trap. > > > > I think it makes sense to have this kind of support for > hard-to-instrument sites within the marker infrastructure, but the cost is > to have two marker flavors : MARK and GEN_MARK (but really GEN_MARK is only > intended for a few sites). > > I must admit that I'm unsure about the use of different marker macros. > How about bitwise flags that could be coded as part of the marker > at the marker site? Something like "MARKER_TYPE_FORCED". This would > still allow some form of toplevel control at the macro definition. > Otherwise there's some digging to be done on a per-marker > basis ... > The problem with your proposal, I guess, is that people will have to add a supplementary parameter to the macro. It is not uncommon to have two slightly versions of macros/functions in the kernel (preempt_enable()/preempt_enable_no_resched(), or macros starting with underscores). Normally, the underscore states that the macro does not do the proper locking itself (this is not our case). Therefore, I would suggest using a name that suggests against what the macro is protected. For instance, a marker pointing to the generic version is only needed to protect against the debug trap handler and should only be used on x86 and x86_64. So, something like MARK_NO_TRAP() would be appropriate : it would be an optimized version for every architecture except x86 and x86_64. The meaning of this macro is : "This is a marker that will never generate a trap because of its activation" (just as a precision : it doesn't say anything about the probe connected to the marker). It also acts as a strong suggestion about what *should not* be done within the probe. Mathieu > Karim > - KRYPTIVA SIGNED MESSAGE - > This email claims to have been packaged by Kryptiva. > To process this email and authenticate its origin, get > the free plugin from: > http://www.kryptiva.com/downloads > > - KRYPTIVA SIGNATURE START - > AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2 > +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF > ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFB0lithGcxNZYBHaLDONjp6eo/LoBwAU6OwGS0m1 > IVdBt6tKzhaPW8MOfncRABgAAABOIEXcozcACATMABkTAAQAggQA > mHAJeFbYUzxSX+zkI0DtoVKcqqSp2Ztc9GtY7ZtuLBmeqg5pW0rIbkhutQiztTXlJQ0Ye9bV > yzEVWd/m7GhDAgRBmyg3kCOt7g7potr1l5J3X5K8TiqtWXbNo3k6AHRlGZyn0190iIBSvf85 > nVh3hKiNPsw8DYs1NKb+KMON+4g= > - KRYPTIVA SIGNATURE END - -- Mathieu Desnoyers Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
- KRYPTIVA PACKAGED MESSAGE - PACKAGING TYPE: SIGNED Hello Mathieu, Mathieu Desnoyers wrote: > Yes, that was indeed the first way I implemented it, as a "disable" option. One of the main thing we have to figure out before I modify this is if we want to have the generic version of markers available in a "forced" manner at the marker site with the GEN_MARK macro instead of the MARK macro (this is the actual implementation). It has proven to be useful to instrument lockdep.c irq > enable/disable tracing functions. The reason why is because they are called just before the trap handler returns and I need it to do XMC on x86 and x86_64. It would therefore cause a recursive trap. > > I think it makes sense to have this kind of support for hard-to-instrument sites within the marker infrastructure, but the cost is to have two marker flavors : MARK and GEN_MARK (but really GEN_MARK is only intended for a few sites). I must admit that I'm unsure about the use of different marker macros. How about bitwise flags that could be coded as part of the marker at the marker site? Something like "MARKER_TYPE_FORCED". This would still allow some form of toplevel control at the macro definition. Otherwise there's some digging to be done on a per-marker basis ... Karim - KRYPTIVA SIGNED MESSAGE - This email claims to have been packaged by Kryptiva. To process this email and authenticate its origin, get the free plugin from: http://www.kryptiva.com/downloads - KRYPTIVA SIGNATURE START - AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2 +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFB0lithGcxNZYBHaLDONjp6eo/LoBwAU6OwGS0m1 IVdBt6tKzhaPW8MOfncRABgAAABOIEXcozcACATMABkTAAQAggQA mHAJeFbYUzxSX+zkI0DtoVKcqqSp2Ztc9GtY7ZtuLBmeqg5pW0rIbkhutQiztTXlJQ0Ye9bV yzEVWd/m7GhDAgRBmyg3kCOt7g7potr1l5J3X5K8TiqtWXbNo3k6AHRlGZyn0190iIBSvf85 nVh3hKiNPsw8DYs1NKb+KMON+4g= - KRYPTIVA SIGNATURE END - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
- KRYPTIVA PACKAGED MESSAGE - PACKAGING TYPE: SIGNED Hello Mathieu, Mathieu Desnoyers wrote: Yes, that was indeed the first way I implemented it, as a disable option. One of the main thing we have to figure out before I modify this is if we want to have the generic version of markers available in a forced manner at the marker site with the GEN_MARK macro instead of the MARK macro (this is the actual implementation). It has proven to be useful to instrument lockdep.c irq enable/disable tracing functions. The reason why is because they are called just before the trap handler returns and I need it to do XMC on x86 and x86_64. It would therefore cause a recursive trap. I think it makes sense to have this kind of support for hard-to-instrument sites within the marker infrastructure, but the cost is to have two marker flavors : MARK and GEN_MARK (but really GEN_MARK is only intended for a few sites). I must admit that I'm unsure about the use of different marker macros. How about bitwise flags that could be coded as part of the marker at the marker site? Something like MARKER_TYPE_FORCED. This would still allow some form of toplevel control at the macro definition. Otherwise there's some digging to be done on a per-marker basis ... Karim - KRYPTIVA SIGNED MESSAGE - This email claims to have been packaged by Kryptiva. To process this email and authenticate its origin, get the free plugin from: http://www.kryptiva.com/downloads - KRYPTIVA SIGNATURE START - AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2 +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFB0lithGcxNZYBHaLDONjp6eo/LoBwAU6OwGS0m1 IVdBt6tKzhaPW8MOfncRABgAAABOIEXcozcACATMABkTAAQAggQA mHAJeFbYUzxSX+zkI0DtoVKcqqSp2Ztc9GtY7ZtuLBmeqg5pW0rIbkhutQiztTXlJQ0Ye9bV yzEVWd/m7GhDAgRBmyg3kCOt7g7potr1l5J3X5K8TiqtWXbNo3k6AHRlGZyn0190iIBSvf85 nVh3hKiNPsw8DYs1NKb+KMON+4g= - KRYPTIVA SIGNATURE END - - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
* Karim Yaghmour ([EMAIL PROTECTED]) wrote: - KRYPTIVA PACKAGED MESSAGE - PACKAGING TYPE: SIGNED Hello Mathieu, Mathieu Desnoyers wrote: Yes, that was indeed the first way I implemented it, as a disable option. One of the main thing we have to figure out before I modify this is if we want to have the generic version of markers available in a forced manner at the marker site with the GEN_MARK macro instead of the MARK macro (this is the actual implementation). It has proven to be useful to instrument lockdep.c irq enable/disable tracing functions. The reason why is because they are called just before the trap handler returns and I need it to do XMC on x86 and x86_64. It would therefore cause a recursive trap. I think it makes sense to have this kind of support for hard-to-instrument sites within the marker infrastructure, but the cost is to have two marker flavors : MARK and GEN_MARK (but really GEN_MARK is only intended for a few sites). I must admit that I'm unsure about the use of different marker macros. How about bitwise flags that could be coded as part of the marker at the marker site? Something like MARKER_TYPE_FORCED. This would still allow some form of toplevel control at the macro definition. Otherwise there's some digging to be done on a per-marker basis ... The problem with your proposal, I guess, is that people will have to add a supplementary parameter to the macro. It is not uncommon to have two slightly versions of macros/functions in the kernel (preempt_enable()/preempt_enable_no_resched(), or macros starting with underscores). Normally, the underscore states that the macro does not do the proper locking itself (this is not our case). Therefore, I would suggest using a name that suggests against what the macro is protected. For instance, a marker pointing to the generic version is only needed to protect against the debug trap handler and should only be used on x86 and x86_64. So, something like MARK_NO_TRAP() would be appropriate : it would be an optimized version for every architecture except x86 and x86_64. The meaning of this macro is : This is a marker that will never generate a trap because of its activation (just as a precision : it doesn't say anything about the probe connected to the marker). It also acts as a strong suggestion about what *should not* be done within the probe. Mathieu Karim - KRYPTIVA SIGNED MESSAGE - This email claims to have been packaged by Kryptiva. To process this email and authenticate its origin, get the free plugin from: http://www.kryptiva.com/downloads - KRYPTIVA SIGNATURE START - AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2 +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFB0lithGcxNZYBHaLDONjp6eo/LoBwAU6OwGS0m1 IVdBt6tKzhaPW8MOfncRABgAAABOIEXcozcACATMABkTAAQAggQA mHAJeFbYUzxSX+zkI0DtoVKcqqSp2Ztc9GtY7ZtuLBmeqg5pW0rIbkhutQiztTXlJQ0Ye9bV yzEVWd/m7GhDAgRBmyg3kCOt7g7potr1l5J3X5K8TiqtWXbNo3k6AHRlGZyn0190iIBSvf85 nVh3hKiNPsw8DYs1NKb+KMON+4g= - KRYPTIVA SIGNATURE END - -- Mathieu Desnoyers Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
- KRYPTIVA PACKAGED MESSAGE - PACKAGING TYPE: SIGNED Mathieu Desnoyers wrote: The problem with your proposal, I guess, is that people will have to add a supplementary parameter to the macro. It is not uncommon to have two slightly versions of macros/functions in the kernel (preempt_enable()/preempt_enable_no_resched(), or macros starting with underscores). Normally, the underscore states that the macro does not do the proper locking itself (this is not our case). Therefore, I would suggest using a name that suggests against what the macro is protected. For instance, a marker pointing to the generic version is only needed to protect against the debug trap handler and should only be used on x86 and x86_64. I can see your point, to a degree. The difference here is that the variants you mention are actually macros that do something, they aren't stubs for code. IOW, you actually know what's happening underneath a foo() vs. _foo() by its name only. Maybe this applies the same to markers, I don't know. But maybe we want to make it easy for those looking at markers that there's a master kill switch somewhere that all markers go through and through which they can all be disabled very simply (say by using a #if 0). While different names *may* be doing that, a same name *does* that. But I don't feel too strongly either way, it's really up to those who maintaining the code to say. Karim - KRYPTIVA SIGNED MESSAGE - This email claims to have been packaged by Kryptiva. To process this email and authenticate its origin, get the free plugin from: http://www.kryptiva.com/downloads - KRYPTIVA SIGNATURE START - AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2 +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFB0lithGcxNZYBHaLDONjp6eo/LoBwAUpXC6F2jf nElq3fnZQpGW97Fk/2QRABgAAABOIEXcvqAADJ5wAB4TAAQAggP/ RQ/W0H9H9bhrZyC67an//DbWC4D38PgLoeMG6Tjvx7jWTpEh79DeQ/+sbb9aYZvbwYwtaVaJ VuPEiRnPZX0mqnOFm+GDzE9jB6202lR0Nzczh1WCifbrrXI7CSEjOwI3ve0jcCoGxTEzZRYj LGxuubV8Hh5HU12zi3Mxgdz031Y= - KRYPTIVA SIGNATURE END - - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
* Karim Yaghmour ([EMAIL PROTECTED]) wrote: > - KRYPTIVA PACKAGED MESSAGE - > PACKAGING TYPE: SIGNED > > Mathieu Desnoyers wrote: > > The main goal of this config option is for embedded systems which doesn't > support live code modification. Maybe we can put that under "embedded > sytems" menu ? > > Not sure whether you had had other feedback on this elsewhere in > the rest of the thread, but yes, this would make sense if the > "embedded" angle is the only reason we need this (and not, say, > performance, etc.) Also, having done that, maybe it would make > some sense to have it be a "disable" rather than "enable": > CONFIG_MARKERS_DISABLE_OPTIMIZATION? > Hi Karim, Yes, that was indeed the first way I implemented it, as a "disable" option. One of the main thing we have to figure out before I modify this is if we want to have the generic version of markers available in a "forced" manner at the marker site with the GEN_MARK macro instead of the MARK macro (this is the actual implementation). It has proven to be useful to instrument lockdep.c irq enable/disable tracing functions. The reason why is because they are called just before the trap handler returns and I need it to do XMC on x86 and x86_64. It would therefore cause a recursive trap. I think it makes sense to have this kind of support for hard-to-instrument sites within the marker infrastructure, but the cost is to have two marker flavors : MARK and GEN_MARK (but really GEN_MARK is only intended for a few sites). Mathieu > Karim > > > - KRYPTIVA SIGNED MESSAGE - > This email claims to have been packaged by Kryptiva. > To process this email and authenticate its origin, get > the free plugin from: > http://www.kryptiva.com/downloads > > - KRYPTIVA SIGNATURE START - > AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2 > +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF > ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFDzvzh+u6zVtolglAZrnE7FOmtZDBwAUTxyTas6N > WLapdnSnAwVHeC06/ioRABgAAABOIEXWD8AACTdnAN8TAAQAggP+ > K8Gk1SWj+c67jiJerodkr1gntoa9dJVVN6InxB824CfKC6flE4JMWtffw0Dxh0cJ8iOQ8UeC > zoWzTs9Z+K9j1CL11CHkIIit3RK3hnfnby6whr4xoZ9UX/BUUv8FVKZeyRg7SbDKlhEZTwIH > 7axjVQJ6MGU7h+0/5dKCDMEtzPY= > - KRYPTIVA SIGNATURE END - -- Mathieu Desnoyers Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
- KRYPTIVA PACKAGED MESSAGE - PACKAGING TYPE: SIGNED Mathieu Desnoyers wrote: > The main goal of this config option is for embedded systems which doesn't support live code modification. Maybe we can put that under "embedded sytems" menu ? Not sure whether you had had other feedback on this elsewhere in the rest of the thread, but yes, this would make sense if the "embedded" angle is the only reason we need this (and not, say, performance, etc.) Also, having done that, maybe it would make some sense to have it be a "disable" rather than "enable": CONFIG_MARKERS_DISABLE_OPTIMIZATION? Karim - KRYPTIVA SIGNED MESSAGE - This email claims to have been packaged by Kryptiva. To process this email and authenticate its origin, get the free plugin from: http://www.kryptiva.com/downloads - KRYPTIVA SIGNATURE START - AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2 +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFDzvzh+u6zVtolglAZrnE7FOmtZDBwAUTxyTas6N WLapdnSnAwVHeC06/ioRABgAAABOIEXWD8AACTdnAN8TAAQAggP+ K8Gk1SWj+c67jiJerodkr1gntoa9dJVVN6InxB824CfKC6flE4JMWtffw0Dxh0cJ8iOQ8UeC zoWzTs9Z+K9j1CL11CHkIIit3RK3hnfnby6whr4xoZ9UX/BUUv8FVKZeyRg7SbDKlhEZTwIH 7axjVQJ6MGU7h+0/5dKCDMEtzPY= - KRYPTIVA SIGNATURE END - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
- KRYPTIVA PACKAGED MESSAGE - PACKAGING TYPE: SIGNED Mathieu Desnoyers wrote: The main goal of this config option is for embedded systems which doesn't support live code modification. Maybe we can put that under embedded sytems menu ? Not sure whether you had had other feedback on this elsewhere in the rest of the thread, but yes, this would make sense if the embedded angle is the only reason we need this (and not, say, performance, etc.) Also, having done that, maybe it would make some sense to have it be a disable rather than enable: CONFIG_MARKERS_DISABLE_OPTIMIZATION? Karim - KRYPTIVA SIGNED MESSAGE - This email claims to have been packaged by Kryptiva. To process this email and authenticate its origin, get the free plugin from: http://www.kryptiva.com/downloads - KRYPTIVA SIGNATURE START - AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2 +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFDzvzh+u6zVtolglAZrnE7FOmtZDBwAUTxyTas6N WLapdnSnAwVHeC06/ioRABgAAABOIEXWD8AACTdnAN8TAAQAggP+ K8Gk1SWj+c67jiJerodkr1gntoa9dJVVN6InxB824CfKC6flE4JMWtffw0Dxh0cJ8iOQ8UeC zoWzTs9Z+K9j1CL11CHkIIit3RK3hnfnby6whr4xoZ9UX/BUUv8FVKZeyRg7SbDKlhEZTwIH 7axjVQJ6MGU7h+0/5dKCDMEtzPY= - KRYPTIVA SIGNATURE END - - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
* Karim Yaghmour ([EMAIL PROTECTED]) wrote: - KRYPTIVA PACKAGED MESSAGE - PACKAGING TYPE: SIGNED Mathieu Desnoyers wrote: The main goal of this config option is for embedded systems which doesn't support live code modification. Maybe we can put that under embedded sytems menu ? Not sure whether you had had other feedback on this elsewhere in the rest of the thread, but yes, this would make sense if the embedded angle is the only reason we need this (and not, say, performance, etc.) Also, having done that, maybe it would make some sense to have it be a disable rather than enable: CONFIG_MARKERS_DISABLE_OPTIMIZATION? Hi Karim, Yes, that was indeed the first way I implemented it, as a disable option. One of the main thing we have to figure out before I modify this is if we want to have the generic version of markers available in a forced manner at the marker site with the GEN_MARK macro instead of the MARK macro (this is the actual implementation). It has proven to be useful to instrument lockdep.c irq enable/disable tracing functions. The reason why is because they are called just before the trap handler returns and I need it to do XMC on x86 and x86_64. It would therefore cause a recursive trap. I think it makes sense to have this kind of support for hard-to-instrument sites within the marker infrastructure, but the cost is to have two marker flavors : MARK and GEN_MARK (but really GEN_MARK is only intended for a few sites). Mathieu Karim - KRYPTIVA SIGNED MESSAGE - This email claims to have been packaged by Kryptiva. To process this email and authenticate its origin, get the free plugin from: http://www.kryptiva.com/downloads - KRYPTIVA SIGNATURE START - AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2 +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFDzvzh+u6zVtolglAZrnE7FOmtZDBwAUTxyTas6N WLapdnSnAwVHeC06/ioRABgAAABOIEXWD8AACTdnAN8TAAQAggP+ K8Gk1SWj+c67jiJerodkr1gntoa9dJVVN6InxB824CfKC6flE4JMWtffw0Dxh0cJ8iOQ8UeC zoWzTs9Z+K9j1CL11CHkIIit3RK3hnfnby6whr4xoZ9UX/BUUv8FVKZeyRg7SbDKlhEZTwIH 7axjVQJ6MGU7h+0/5dKCDMEtzPY= - KRYPTIVA SIGNATURE END - -- Mathieu Desnoyers Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
* Andrew Morton ([EMAIL PROTECTED]) wrote: > On Sun, 11 Feb 2007 15:03:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> > wrote: > > > Linux Kernel Markers, non optimized architectures > > > > This patch also includes marker code for non optimized architectures. > > I think once we've done this we can nuke > CONFIG_MARKERS_ENABLE_OPTIMIZATION? (Please, let it be true). > Hi Andrew, The main goal of this config option is for embedded systems which doesn't support live code modification. Maybe we can put that under "embedded sytems" menu ? -- Mathieu Desnoyers Computer Engineering Ph.D. Candidate, École Polytechnique de Montréal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
* Andrew Morton ([EMAIL PROTECTED]) wrote: On Sun, 11 Feb 2007 15:03:27 -0500 Mathieu Desnoyers [EMAIL PROTECTED] wrote: Linux Kernel Markers, non optimized architectures This patch also includes marker code for non optimized architectures. I think once we've done this we can nuke CONFIG_MARKERS_ENABLE_OPTIMIZATION? (Please, let it be true). Hi Andrew, The main goal of this config option is for embedded systems which doesn't support live code modification. Maybe we can put that under embedded sytems menu ? -- Mathieu Desnoyers Computer Engineering Ph.D. Candidate, École Polytechnique de Montréal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
On Sun, 11 Feb 2007 15:03:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > Linux Kernel Markers, non optimized architectures > > This patch also includes marker code for non optimized architectures. I think once we've done this we can nuke CONFIG_MARKERS_ENABLE_OPTIMIZATION? (Please, let it be true). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
On Sun, 11 Feb 2007 15:03:27 -0500 Mathieu Desnoyers [EMAIL PROTECTED] wrote: Linux Kernel Markers, non optimized architectures This patch also includes marker code for non optimized architectures. I think once we've done this we can nuke CONFIG_MARKERS_ENABLE_OPTIMIZATION? (Please, let it be true). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/05] Linux Kernel Markers, non optimized architectures
Linux Kernel Markers, non optimized architectures This patch also includes marker code for non optimized architectures. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> --- /dev/null +++ b/include/asm-arm/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include --- /dev/null +++ b/include/asm-cris/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include --- /dev/null +++ b/include/asm-frv/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include --- /dev/null +++ b/include/asm-generic/marker.h @@ -0,0 +1,40 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Generic header. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + * + * Note : the empty asm volatile with read constraint is used here instead of a + * "used" attribute to fix a gcc 4.1.x bug. + */ + +#ifdef CONFIG_MARKERS + +#define GEN_MARK(name, format, args...) \ + do { \ + static marker_probe_func *__mark_call_##name = \ + __mark_empty_function; \ + static char __marker_enable_##name = 0; \ + static const struct __mark_marker_c __mark_c_##name \ + __attribute__((section(".markers.c"))) = \ + { #name, &__mark_call_##name, format, \ + MARKER_GENERIC } ; \ + static const struct __mark_marker __mark_##name \ + __attribute__((section(".markers"))) = \ + { &__mark_c_##name, &__marker_enable_##name } ; \ + asm volatile ( "" : : "i" (&__mark_##name)); \ + __mark_check_format(format, ## args); \ + if (unlikely(__marker_enable_##name)) { \ + preempt_disable(); \ + (*__mark_call_##name)(format, ## args); \ + preempt_enable(); \ + } \ + } while (0) + + +#define GEN_MARK_ENABLE_IMMEDIATE_OFFSET 0 +#define GEN_MARK_ENABLE_TYPE char + +#endif --- /dev/null +++ b/include/asm-h8300/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include --- /dev/null +++ b/include/asm-ia64/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include --- /dev/null +++ b/include/asm-m32r/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include --- /dev/null +++ b/include/asm-m68k/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include --- /dev/null +++ b/include/asm-m68knommu/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include --- /dev/null +++ b/include/asm-mips/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include --- /dev/null +++ b/include/asm-parisc/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include --- /dev/null +++ b/include/asm-ppc/marker.h @@ -0,0 +1,13
[PATCH 05/05] Linux Kernel Markers, non optimized architectures
Linux Kernel Markers, non optimized architectures This patch also includes marker code for non optimized architectures. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] --- /dev/null +++ b/include/asm-arm/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include asm-generic/marker.h --- /dev/null +++ b/include/asm-cris/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include asm-generic/marker.h --- /dev/null +++ b/include/asm-frv/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include asm-generic/marker.h --- /dev/null +++ b/include/asm-generic/marker.h @@ -0,0 +1,40 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Generic header. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + * + * Note : the empty asm volatile with read constraint is used here instead of a + * used attribute to fix a gcc 4.1.x bug. + */ + +#ifdef CONFIG_MARKERS + +#define GEN_MARK(name, format, args...) \ + do { \ + static marker_probe_func *__mark_call_##name = \ + __mark_empty_function; \ + static char __marker_enable_##name = 0; \ + static const struct __mark_marker_c __mark_c_##name \ + __attribute__((section(.markers.c))) = \ + { #name, __mark_call_##name, format, \ + MARKER_GENERIC } ; \ + static const struct __mark_marker __mark_##name \ + __attribute__((section(.markers))) = \ + { __mark_c_##name, __marker_enable_##name } ; \ + asm volatile ( : : i (__mark_##name)); \ + __mark_check_format(format, ## args); \ + if (unlikely(__marker_enable_##name)) { \ + preempt_disable(); \ + (*__mark_call_##name)(format, ## args); \ + preempt_enable(); \ + } \ + } while (0) + + +#define GEN_MARK_ENABLE_IMMEDIATE_OFFSET 0 +#define GEN_MARK_ENABLE_TYPE char + +#endif --- /dev/null +++ b/include/asm-h8300/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include asm-generic/marker.h --- /dev/null +++ b/include/asm-ia64/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include asm-generic/marker.h --- /dev/null +++ b/include/asm-m32r/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include asm-generic/marker.h --- /dev/null +++ b/include/asm-m68k/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include asm-generic/marker.h --- /dev/null +++ b/include/asm-m68knommu/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include asm-generic/marker.h --- /dev/null +++ b/include/asm-mips/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include asm-generic/marker.h --- /dev/null +++ b/include/asm-parisc/marker.h @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + *