diff for duplicates of <1351013449.9070.5.camel@hornet>

diff --git a/a/1.txt b/N1/1.txt
index ec6e8df..ee67ef7 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -23,7 +23,8 @@ patches.
 
 
 
-== Option 1: Trace event =
+=== Option 1: Trace event ===
+
 This seems to be the "cheapest" option. Simply defining a trace event
 that can be generated by a hwmon (or any other) driver makes the
 interesting data immediately available to any ftrace/perf user. Of
@@ -32,7 +33,8 @@ a good place to start with.
 
 The question is how to define it... I've came up with two prototypes:
 
-= Generic hwmon trace event 
+= Generic hwmon trace event =
+
 This one allows any driver to generate a trace event whenever any
 "hwmon attribute" (measured value) gets updated. The rate at which the
 updates happen can be controlled by already existing "update_interval"
@@ -67,7 +69,8 @@ One issue with this is that some external knowledge is required to
 relate a number to a processor core. Or maybe it's not an issue at all
 because it should be left for the user(space)?
 
-= CPU power/energy/temperature trace event 
+= CPU power/energy/temperature trace event =
+
 This one is designed to emphasize the relation between the measured
 value (whether it is energy, temperature or any other physical
 phenomena, really) and CPUs, so it is quite specific (too specific?)
@@ -116,7 +119,8 @@ any alternative suggestions :-)
 
 
 
-== Option 2: hwmon perf PMU =
+=== Option 2: hwmon perf PMU ===
+
 Although the trace event makes it possible to obtain interesting
 information using perf, the user wouldn't be able to treat the
 energy meter as a normal data source. In particular there would
@@ -125,7 +129,8 @@ be no way of creating a group of events consisting eg. of a
 read. The only way to get this done is to implement a perf PMU
 backend providing "environmental data" to the user.
 
-= High-level hwmon API and PMU 
+= High-level hwmon API and PMU =
+
 Current hwmon subsystem does not provide any abstraction for the
 measured values and requires particular drivers to create specified
 sysfs attributes than used by userspace libsensors. This makes
@@ -139,14 +144,16 @@ in-kernel API for values enumeration and access. That way the core
 could also register a "hwmon PMU" with the perf framework providing
 data from all "compliant" drivers.
 
-= A driver-specific PMU 
+= A driver-specific PMU =
+
 Of course a particular driver could register its own perf PMU on its
 own. It's certainly an option, just very suboptimal in my opinion.
 Or maybe not? Maybe the task is so specialized that it makes sense?
 
 
 
-== Option 3: CPU power(energy) monitoring framework =
+=== Option 3: CPU power(energy) monitoring framework ===
+
 And last but not least, maybe the problem deserves some dedicated
 API? Something that would take providers and feed their data into
 interested parties, in particular a perf PMU implementation and
@@ -164,11 +171,3 @@ list, but if I missed anyone - please, do let them (and/or me) know.
 Best regards and thanks for participation in the discussion!
 
 Pawel
-
-
-
-
-_______________________________________________
-lm-sensors mailing list
-lm-sensors@lm-sensors.org
-http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
diff --git a/a/content_digest b/N1/content_digest
index 8b5ba35..d88a7bc 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,34 +1,7 @@
- "From\0Pawel Moll <pawel.moll@arm.com>\0"
- "Subject\0[lm-sensors] [RFC] Energy/power monitoring within the kernel\0"
- "Date\0Tue, 23 Oct 2012 17:30:49 +0000\0"
- "To\0Amit Daniel Kachhap <amit.kachhap@linaro.org>"
-  Zhang Rui <rui.zhang@intel.com>
-  Viresh Kumar <viresh.kumar@linaro.org>
-  Daniel Lezcano <daniel.lezcano@linaro.org>
-  Jean Delvare <khali@linux-fr.org>
-  Guenter Roeck <linux@roeck-us.net>
-  Steven Rostedt <rostedt@goodmis.org>
-  Frederic Weisbecker <fweisbec@gmail.com>
-  Ingo Molnar <mingo@elte.hu>
-  Jesper Juhl <jj@chaosbits.net>
-  Thomas Renninger <trenn@suse.de>
-  Jean Pihet <jean.pihet@newoldbits.com>
-  Amit Daniel Kachhap <amit.kachhap@linaro.org>
-  Zhang Rui <rui.zhang@intel.com>
-  Viresh Kumar <viresh.kumar@linaro.org>
-  Daniel Lezcano <daniel.lezcano@linaro.org>
-  Jean Delvare <khali@linux-fr.org>
-  Guenter Roeck <linux@roeck-us.net>
-  Steven Rostedt <rostedt@goodmis.org>
-  Frederic Weisbecker <fweisbec@gmail.com>
-  Ingo Molnar <mingo@elte.hu>
-  Jesper Juhl <jj@chaosbits.net>
-  Thomas Renninger <trenn@suse.de>
- " Jean Pihet <jean.pihet@newoldbits.com>\0"
- "Cc\0linux-kernel@vger.kernel.org"
-  linux-arm-kernel@lists.infradead.org
-  lm-sensors@lm-sensors.org
- " linaro-dev@lists.linaro.org\0"
+ "From\0pawel.moll@arm.com (Pawel Moll)\0"
+ "Subject\0[RFC] Energy/power monitoring within the kernel\0"
+ "Date\0Tue, 23 Oct 2012 18:30:49 +0100\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "Greetings All,\n"
@@ -56,7 +29,8 @@
  "\n"
  "\n"
  "\n"
- "== Option 1: Trace event =\n"
+ "=== Option 1: Trace event ===\n"
+ "\n"
  "This seems to be the \"cheapest\" option. Simply defining a trace event\n"
  "that can be generated by a hwmon (or any other) driver makes the\n"
  "interesting data immediately available to any ftrace/perf user. Of\n"
@@ -65,7 +39,8 @@
  "\n"
  "The question is how to define it... I've came up with two prototypes:\n"
  "\n"
- "= Generic hwmon trace event \n"
+ "= Generic hwmon trace event =\n"
+ "\n"
  "This one allows any driver to generate a trace event whenever any\n"
  "\"hwmon attribute\" (measured value) gets updated. The rate at which the\n"
  "updates happen can be controlled by already existing \"update_interval\"\n"
@@ -100,7 +75,8 @@
  "relate a number to a processor core. Or maybe it's not an issue at all\n"
  "because it should be left for the user(space)?\n"
  "\n"
- "= CPU power/energy/temperature trace event \n"
+ "= CPU power/energy/temperature trace event =\n"
+ "\n"
  "This one is designed to emphasize the relation between the measured\n"
  "value (whether it is energy, temperature or any other physical\n"
  "phenomena, really) and CPUs, so it is quite specific (too specific?)\n"
@@ -149,7 +125,8 @@
  "\n"
  "\n"
  "\n"
- "== Option 2: hwmon perf PMU =\n"
+ "=== Option 2: hwmon perf PMU ===\n"
+ "\n"
  "Although the trace event makes it possible to obtain interesting\n"
  "information using perf, the user wouldn't be able to treat the\n"
  "energy meter as a normal data source. In particular there would\n"
@@ -158,7 +135,8 @@
  "read. The only way to get this done is to implement a perf PMU\n"
  "backend providing \"environmental data\" to the user.\n"
  "\n"
- "= High-level hwmon API and PMU \n"
+ "= High-level hwmon API and PMU =\n"
+ "\n"
  "Current hwmon subsystem does not provide any abstraction for the\n"
  "measured values and requires particular drivers to create specified\n"
  "sysfs attributes than used by userspace libsensors. This makes\n"
@@ -172,14 +150,16 @@
  "could also register a \"hwmon PMU\" with the perf framework providing\n"
  "data from all \"compliant\" drivers.\n"
  "\n"
- "= A driver-specific PMU \n"
+ "= A driver-specific PMU =\n"
+ "\n"
  "Of course a particular driver could register its own perf PMU on its\n"
  "own. It's certainly an option, just very suboptimal in my opinion.\n"
  "Or maybe not? Maybe the task is so specialized that it makes sense?\n"
  "\n"
  "\n"
  "\n"
- "== Option 3: CPU power(energy) monitoring framework =\n"
+ "=== Option 3: CPU power(energy) monitoring framework ===\n"
+ "\n"
  "And last but not least, maybe the problem deserves some dedicated\n"
  "API? Something that would take providers and feed their data into\n"
  "interested parties, in particular a perf PMU implementation and\n"
@@ -196,14 +176,6 @@
  "\n"
  "Best regards and thanks for participation in the discussion!\n"
  "\n"
- "Pawel\n"
- "\n"
- "\n"
- "\n"
- "\n"
- "_______________________________________________\n"
- "lm-sensors mailing list\n"
- "lm-sensors@lm-sensors.org\n"
- http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
+ Pawel
 
-b8b745f518759b663b52a68c5115c23de8e826591c3c5a005aff6e993b593c81
+a8d8fc3f03ee1b8b34fce7b2547735ceaf3bc85928e71ee8180193bb2febcd18
