linux-kernel - Re: [PATCH] tracing: Export key trace event symbols

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5537CDDD.2080903@fnal.gov>
Date:	Wed, 22 Apr 2015 11:35:41 -0500
From:	Ron Rechenmacher <ron@...l.gov>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	David Ahern <dsahern@...il.com>,
	Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	<linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	"Stephane Eranian" <eranian@...gle.com>
Subject: Re: [PATCH] tracing: Export key trace event symbols

Thanks, Steve :)

I was working on a reply to your previous email but I'll reply here.
I'm happy with how this is going and I'm really appreciative of how
you have/are handling (managing) this. Thanks!

Assuming I'm only getting the tip of the ice berg of "normal Linux kernel
development," I don't know if it's reasonable to achieve a balance between
discussing "accepting the patch" and "what I'm doing with TRACE."

If I may, I can separate the two as follows (and focusing more on "accepting the patch"):
In my 30 year evolution of TRACE, a significant point came (somewhere in the
1990's) when, with Vxworks, I noticed that they had a "task switch hook add" routine
and I was able to incorporate kernel task switching events in with the application
traces. My first patches to the linux-2.2 kernel included a patch to the
scheduler and interrupts came quickly there after.  I was always wondering
if Linux would one day provide "task switch hook" capability.
In early 2013, when I started the v3 of TRACE, I was extremely happy to find
the symbol "register_trace_sched_switch" --- this was all I needed and I thought
"they did it."

With the understanding, as has been mentioned before, that "only the user space ABI is
what we keep stable" and that before commit de7b2973903c (tracepoint: Use struct pointer
instead of name hash for reg/unreg tracepoints) it was just "lucky" that I could use
the register_tracepoint_* routines as somewhat generic "add hook" routines (from
external modules), is it now reasonable to accept my patch to allow external modules
to "add hooks" to key events in Linux?  Why or why not?

Thanks,
Ron

Steven Rostedt wrote on 04/22/15 10:44:
> On Wed, 22 Apr 2015 09:36:20 -0600
> David Ahern <dsahern@...il.com> wrote:
>
>> One of the key requirements is a common time basis (e.g.,
>> CLOCK_MONOTONIC or PERF_CLOCK) to be able to merge the events properly.
>> I have a kernel module that exports perf_clock to userspace via
>> clock_gettime; the 4.1 kernel should have the code that allows the clock
>> id to be specified providing a solution to this problem.
>
> Ron,
>
> I should have warned you. This is normal Linux kernel development.
> Someone posts a simple patch to make something of there's work better,
> and it ends up becoming a massive undertaking to come up with a solution
> that makes Linux in general a better operating system ;-)
>
> -- Steve
>

-- 
Ron Rechenmacher
Engineer
Fermi National Accelerator Laboratory
Batavia, IL  60510
--
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/