Commit b4282c79 authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab Committed by Jonathan Corbet

irqflags-tracing.txt: standardize document format

Each text file under Documentation follows a different
format. Some doesn't even have titles!

Change its representation to follow the adopted standard,
using ReST markups for it to be parseable by Sphinx:

There isn't much to be done here: just mark the document
title as such and add a :Author:.

While here, use upper case at the beginning of a few paragraphs
that start with lower case.
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
parent 1642a1e6
=======================
IRQ-flags state tracing IRQ-flags state tracing
=======================
started by Ingo Molnar <mingo@redhat.com> :Author: started by Ingo Molnar <mingo@redhat.com>
the "irq-flags tracing" feature "traces" hardirq and softirq state, in The "irq-flags tracing" feature "traces" hardirq and softirq state, in
that it gives interested subsystems an opportunity to be notified of that it gives interested subsystems an opportunity to be notified of
every hardirqs-off/hardirqs-on, softirqs-off/softirqs-on event that every hardirqs-off/hardirqs-on, softirqs-off/softirqs-on event that
happens in the kernel. happens in the kernel.
...@@ -14,7 +16,7 @@ CONFIG_PROVE_RWSEM_LOCKING will be offered on an architecture - these ...@@ -14,7 +16,7 @@ CONFIG_PROVE_RWSEM_LOCKING will be offered on an architecture - these
are locking APIs that are not used in IRQ context. (the one exception are locking APIs that are not used in IRQ context. (the one exception
for rwsems is worked around) for rwsems is worked around)
architecture support for this is certainly not in the "trivial" Architecture support for this is certainly not in the "trivial"
category, because lots of lowlevel assembly code deal with irq-flags category, because lots of lowlevel assembly code deal with irq-flags
state changes. But an architecture can be irq-flags-tracing enabled in a state changes. But an architecture can be irq-flags-tracing enabled in a
rather straightforward and risk-free manner. rather straightforward and risk-free manner.
...@@ -41,7 +43,7 @@ irq-flags-tracing support: ...@@ -41,7 +43,7 @@ irq-flags-tracing support:
excluded from the irq-tracing [and lock validation] mechanism via excluded from the irq-tracing [and lock validation] mechanism via
lockdep_off()/lockdep_on(). lockdep_off()/lockdep_on().
in general there is no risk from having an incomplete irq-flags-tracing In general there is no risk from having an incomplete irq-flags-tracing
implementation in an architecture: lockdep will detect that and will implementation in an architecture: lockdep will detect that and will
turn itself off. I.e. the lock validator will still be reliable. There turn itself off. I.e. the lock validator will still be reliable. There
should be no crashes due to irq-tracing bugs. (except if the assembly should be no crashes due to irq-tracing bugs. (except if the assembly
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment