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: <p73odff5j1x.fsf@bingen.suse.de>
Date:	04 Oct 2007 11:24:26 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	"David J. Wilder" <dwilder@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	randy.dunlap@...cle.com, hch@...radead.org,
	systemtap@...rces.redhat.com
Subject: Re: [patch 1/3]  Trace code and documentation

"David J. Wilder" <dwilder@...ibm.com> writes:
> @@ -0,0 +1,160 @@
> +Trace Setup and Control
> +=======================
> +In the kernel, the trace interface provides a simple mechanism for
> +starting and managing data channels (traces) to user space.

Wasn't relayfs supposed to do that already? Why do you need another
wrapper around it? 

Is this also really still faster than a printk below log level
(without console driver overhead). If not then why not just
use printk? 

Especially your example is worrying. It essentially defines a new
printk. I think there is a case for a fast logging subsystem because
printk() is admittedly a little slow [somewhat slow below log level
and incredible slow above it]

But fast means binary items (not sprintf), no global locks, not
multiple layers, per CPU etc.. But your example and this patch has all
this and I bet it is not very fast.

Is the result (e.g. the trace example module) still any faster
than printk below log level? If not then why bother.

Adding another slow logger would be just a waste of time imho.
It just means that everybody who needs a fast logger just need
to reimplement their own anyways. And the people who can tolerate
slow loggers are probably already adequately served by 
printk. Also there is already direct relayfs.

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