linux-kernel - What is the right practice to get new code upstream( was Fwd: [patch] a simple hardware detector for latency as well as throughput ver. 0.1.0)

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: <CAJRGBZw2TctmBxRuA-byaGNCs=1v+M-1PXSm+OuwWApSqu7UjA@mail.gmail.com>
Date:	Tue, 12 Jun 2012 20:57:02 +0800
From:	Luming Yu <luming.yu@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>, tglx@...utronix.de,
	sfr@...b.auug.org.au, Andrew Morton <akpm@...ux-foundation.org>,
	jcm@...masters.org, linux-next@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>, torvalds@...ux-foundation.org
Subject: What is the right practice to get new code upstream( was Fwd: [patch]
 a simple hardware detector for latency as well as throughput ver. 0.1.0)

Hi All,

I must have forgotten cc key persons. Sorry to make noise again.
I need to know what the right practice is to get your attention to
accept a new tool upstream like this one.

About the tool:

It's unique. It's simple. But it's valuable, But it's still a starting point.

The tool is based on Jcm's latency testing tool in RT tree to detect
SMI caused problem.
Basically it's a testing tool to measure latency and bandwidth of raw
hardware instructions and component functions exclusively in
stop_machine context. It's a kernel module that can be run separately
from kernel boot. The Goal is to test out hardware/BIOS caused
problems in 2 minutes. To me, capable of measuring the intrinsic of
hardware on which we build our software is always a better idea than
blindly looking for data from any documents. In current version of the
tool, we have a basic sampling facility and TSC test ready for x86. I
plan to add more test into this tool to enrich our tool set in Linux.

Any inputs are appreciated. :-)

Thanks for your time.
/l

---------- Forwarded message ----------
From: Luming Yu <luming.yu@...il.com>
Date: Tue, Jun 12, 2012 at 11:42 AM
Subject: Fwd: [patch] a simple hardware detector for latency as well
as throughput ver. 0.1.0
To: LKML <linux-kernel@...r.kernel.org>

Hello everyone,

I'm trying to push a new tool upstream. I'd like to hear back from you
what the best practice is to get the job done.

Thanks,
Luming

---------- Forwarded message ----------
From: Luming Yu <luming.yu@...il.com>
Date: Mon, Jun 11, 2012 at 9:59 PM
Subject: Fwd: [patch] a simple hardware detector for latency as well
as throughput ver. 0.1.0
To: sfr@...b.auug.org.au
Cc: Andrew Morton <akpm@...ux-foundation.org>, jcm@...masters.org,
linux-next@...r.kernel.org

Hi,

I'd like to know if the patch looks good for linux-next to find its
way upstream in 3.6.

Thanks and regards,
Luming

---------- Forwarded message ----------
From: Luming Yu <luming.yu@...il.com>
Date: Wed, May 30, 2012 at 7:47 AM
Subject: Fwd: [patch] a simple hardware detector for latency as well
as throughput ver. 0.1.0
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: jcm@...masters.org

Hello akpm,

I'd like to push the patch to upstream, but I'm not sure if jcm has
extra bandwidth although he is also interested in having the tool
upstream..So I'd like ping you to check if there is any chance to
queue it up in your tree first.I will enhance it further after it's
upstream.

Thanks,
Luming

---------- Forwarded message ----------
From: Luming Yu <luming.yu@...il.com>
Date: Tue, May 29, 2012 at 4:37 AM
Subject: [patch] a simple hardware detector for latency as well as
throughput ver. 0.1.0
To: jcm@...masters.org
Cc: linux-kernel@...r.kernel.org

Hi Jon,

The patch is the fist step to test some basic hardware functions like
TSC to help people understand if there is any hardware latency as well as
throughput problem exposed on bare metal or left behind by BIOS or
interfered by SM. Currently the patch tests hardware features
(tsc,freq, and rdrandom whiich is new instruction to get random
number) in stop_machine context. I will add more after the first step
get merged for those guys who want to directly play with new hardware
functions.

I suppose I can add your signed-off-by as the code is derived from your
hwlat_dector.

I'm also reuqesting if you are going to queue it up somewhere that can
be pulled into 3.5.

Of cause, I will update the patch based upon any comments that you
think must be fixed for 3.5 merge.

Thanks,
Luming

Signed-off-by Luming Yu <luming.yu@...el.com>

 Kconfig   |    7
 Makefile  |    2
 hw_test.c |  954
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 963 insertions(+)
--
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/