Hi,
The Linux Kernel Markers have been reworked to now depend on the "Conditional
Calls" as a basic infrastructure for enabling the calls to the function
pointers (probes).
The second major change in this release is the use of a hash table to keep track
of the enabled markers : it permits it issue the marker_arm_probe before loading
a module containing the specified probe. The probe connexion to the marker is
done both when the marker is armed and at module load time. It fixes an
unexpected behavior of the previous version, which was due to the fact that
users might have expected that the markers would be set for newly loaded
modules. Since there is no dependency between the marker and modules, the order
could easily be wrong.
A hash table using a hash of the marker name is used to give O(1) lookup at
module load time.
This serie of patches depends on the conditional calls. Please add at the end of
the 2.6.22-mm1 series:
use-extra_rwdata-in-architectures.patch
#
linux-kernel-markers-architecture-independent-code.patch
linux-kernel-markers-hash-table.patch
linux-kernel-markers-kconfig-menus.patch
linux-kernel-markers-documentation.patch
linux-kernel-markers-port-blktrace-to-markers.patch
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
Same here : it applies at the end of 2.6.21-mm2, not 2.6.22-mm1 as said
in my message.
* Mathieu Desnoyers ([email protected]) wrote:
> Hi,
>
> The Linux Kernel Markers have been reworked to now depend on the "Conditional
> Calls" as a basic infrastructure for enabling the calls to the function
> pointers (probes).
>
> The second major change in this release is the use of a hash table to keep track
> of the enabled markers : it permits it issue the marker_arm_probe before loading
> a module containing the specified probe. The probe connexion to the marker is
> done both when the marker is armed and at module load time. It fixes an
> unexpected behavior of the previous version, which was due to the fact that
> users might have expected that the markers would be set for newly loaded
> modules. Since there is no dependency between the marker and modules, the order
> could easily be wrong.
>
> A hash table using a hash of the marker name is used to give O(1) lookup at
> module load time.
>
> This serie of patches depends on the conditional calls. Please add at the end of
> the 2.6.22-mm1 series:
>
> use-extra_rwdata-in-architectures.patch
> #
> linux-kernel-markers-architecture-independent-code.patch
> linux-kernel-markers-hash-table.patch
> linux-kernel-markers-kconfig-menus.patch
> linux-kernel-markers-documentation.patch
> linux-kernel-markers-port-blktrace-to-markers.patch
>
> Mathieu
>
>
> --
> Mathieu Desnoyers
> Computer Engineering Ph.D. Student, 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/
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68