linux-kernel - Re: [RFC][Patch 2/2] markers: example of irq regular kernel markers

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: <485DD589.6070503@redhat.com>
Date:	Sun, 22 Jun 2008 00:31:05 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	"Frank Ch. Eigler" <fche@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>
CC:	Steven Rostedt <rostedt@...dmis.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	systemtap-ml <systemtap@...rces.redhat.com>,
	Hideo AOKI <haoki@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC][Patch 2/2] markers: example of irq regular kernel markers

Hi,

Frank Ch. Eigler wrote:
>> I do think we must make a clear distinction between these cases because:
>>
>> 1) tracers provide a kernel<->user interface - and whilst we don't
>> have a stable in-kernel API/ABI we are anal about the kernel/user
>> boundary.  Andrew also greatly worries about this aspect.
> 
> Well, how to set Andrew's mind at ease then, beyond what we've already
> said?  Back a few months ago, both systemtap and lttng guys - the
> primary user-space clients - have said that we are fine with this
> interface changing.  We each have mechanisms to adapt.
> 
>> 2) it highly uglyfies the code, Frank doesn't need to maintain it,
>> so its easy for him to say. But IMHO its much harder to read code
>> that is littered with debug statements that it is to read regular
>> code.
> 
> Then don't put too many in, or hide them with inline functions.
> 
>>  3) it bloats the kernel,.. while it may not be fast path bloat, all
>> that marker stuff does go somewhere.
> 
> That bloat has been quantified and appears negligible in space and time.
> 
>> So, while I see the value of 'stable' mark sites for 'stable'
>> events, I'm dead-set against littering the kernel with markers just
>> because we can, and hoping they might some day be useful for
>> someone.
> 
> We're in violent agreement.  No one suggested "littering just because
> we can".  The initial lttng suite of markers consisted of about one
> hundred *in total*.  If some other subsystem maintainer runs amok and
> adds thousands, please take it up with them, not with us.

Indeed.

Peter, I thought, we were discussing what interface we could accept,
not how many or where tracepoints we could accept. Or, am I misreading?

I know that if someone pushes markers into kernel in his own sweet way,
of course, the kernel code will be bloated endlessly. But I also know
why we review patches and send Ack/Nack before merging them to the tree.
(If you still worry about it, we might be able to make linux-markers
git tree, and review all regular markers on it)

I think and agree that we should make clear policies and criteria of
acceptance of each marker, but it should be discussed on actual
marker uses patches after making agreement for the interface.

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@...hat.com

--
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/