lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070801215723.GA10470@ittc.ku.edu>
Date:	Wed, 1 Aug 2007 16:57:24 -0500
From:	nwatkins@...c.ku.edu
To:	mathieu.desnoyers@...ymtl.ca
Cc:	nwatkins@...c.ku.edu, linux-kernel@...r.kernel.org
Subject: [patch 0/1] extending low-level markers

Mathieu

I have been working with your Kernel Markers infrastructure now for some
time and have run into an extendability issue.

Essentially I am failing to find a way to extend the current
__trace_mark macro with site-specific context. That is, I would like the
ability to create different 'types' of instrumentation points by bulding
upon the __trace_mark macro. A consumer of this marker could examine
the type of marker, and attach an appropriate callback function /
private data.

I have included a patch which adds a flavor field to the __trace_mark
macro. This simplified example demonstrates the functionality I'm
looking for:

#define __trace_mark(flavor, name, format, args...)
		<current macro plus the flavor field>

#define marker_flavor_XXX(name, format, args...)
		__trace_mark(XXX, name, format, args)

Here a marker of type XXX is build upon the __trace_mark macro. When a
consumer of type XXX finds markers with the XXX flavor appropriate
registration can take place.

Unless I don't fully understand all the use cases of the markers, I
don't see any other way to do this except to encode the 'type'
information in the name of the marker, and require the consumer to parse
the string to determine the type. Restricting the names of the markers
in this way seems like a bad solution.

Any help and feedback is greatly appreciated.

- Noah

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ