linux-kernel - Re: [patch 00/37] Linux Kernel Markers instrumentation for sched-devel.git

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]

Date:	Mon, 28 Apr 2008 18:25:06 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [patch 00/37] Linux Kernel Markers instrumentation for	sched-devel.git

Peter Zijlstra wrote:
> On Mon, 2008-04-28 at 11:36 -0700, Andrew Morton wrote:
>> On Sat, 26 Apr 2008 21:38:54 +0200 Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
>>> lets hide the ugly bits.
>> It hides the cosmetically-ugly bits, but not the deeply ugly: each of these
>> trace points is an extension to the kernel->userspace API, with all that
>> this implies.
> 
> Agreed, and I'm rather concerned about that as well. OTOH its very
> unlikely we'll ever have a Linux that will not have a context switch, or
> task wakeup operation.
> 
> So tracing these and things like syscall seem safe enough to do -
> although I wish it wouldn't look so ugly. 

What would you think about the basic-hardware events like
interruptions, and exceptions?:-)

> As for some of these other trace points in this set, dubious.
> 
> We can of course clearly state that any marker is free of API
> constraints and users will have to cope with them changing. But I'm not
> sure that's a realistic position.

BTW, I also have a question about the maintenance policy of markers.
Who will pay a cost for updating (maintaining) those trace points
according to changing logic of the kernel?

I think that each developer who modifies the kernel has to fix
trace points just for removing compile-errors. They can (but don't need to)
leave, update or remove the trace points to fit their changes, because they
knows their changes precisely, but they don't know why the trace points are
there and what information is required.
So, trace points should be basically maintained by trace point maintainers
who know all about the trace points.
is that right?

Thanks,

Best regards,

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