diff for duplicates of <BANLkTimkHZ01LfRoOha79QPyRaaDKo7T-Q@mail.gmail.com>

diff --git a/a/1.txt b/N1/1.txt
index cd89e73..1756722 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -2,9 +2,9 @@
 > On Friday 01 April 2011, Ingo Molnar wrote:
 >> IMO the right answer is what Linus and Thomas outlined:
 >>
->>    1) provide a small number of clean examples and clean abstractions
->>    2) to not pull new crap from that point on
->>    3) do this gradually but consistently
+>> ? ?1) provide a small number of clean examples and clean abstractions
+>> ? ?2) to not pull new crap from that point on
+>> ? ?3) do this gradually but consistently
 >>
 >> I.e. make all your requirements technical and actionable - avoid sweeping,
 >> impossible to meet requirements. Do not require people to clean up all of the
@@ -32,16 +32,16 @@
 >
 > 1. The core arch code is not a problem (Russell does a great job here)
 > 2. The platform specific code contains a lot of crap that doesn't belong there
->   (not enough reviewers to push back on crap)
+> ? (not enough reviewers to push back on crap)
 > 3. The amount of crap in platform specfic files is growing exponentially,
->   despite the best efforts of a handful of people to clean it up.
+> ? despite the best efforts of a handful of people to clean it up.
 > 4. Having one source file per board does not scale any more.
 > 5. Discoverable hardware would solve this, but is not going to happen
->   in practice.
+> ? in practice.
 > 6. Board firmware would not solve this and is usually not present.
 > 7. Boot loaders can not be trusted to pass valid information
 > 8. Device tree blobs can solve a lot of the problems, and nobody has
->   come up with a better solution.
+> ? come up with a better solution.
 
 ARM BSP is still blasting! we are planning to merge our new ARM
 cortex-a9 SoC into kernel. So I am just wondering whether traditional
@@ -80,38 +80,38 @@ we want to fix more issues this email pointed out before we send
 patches.
 
 > 9. All interesting work is going into a handful of platforms, all of which
->   are ARMv7 based.
+> ? are ARMv7 based.
 > 10. We do not want to discontinue support for old boards that work fine.
 > 11. Massive changes to existing platforms would cause massive breakage.
 > 12. Supporting many different boards with a single kernel binary is a
->    useful goal.
+> ? ?useful goal.
 > 13. Infrastructure code should be cross-platform, not duplicated across
->    platforms.
+> ? ?platforms.
 > 14. 32 bit ARM is hitting the wall in the next years (Cortex-A15 is
->    actually adding PAE support, which has failed to solve this on
->    other architectures).
+> ? ?actually adding PAE support, which has failed to solve this on
+> ? ?other architectures).
 > 15. We need to solve the platform problem before 64 bit support comes
->    and adds another dimension to the complexity.
+> ? ?and adds another dimension to the complexity.
 >
 > Based on these assumptions, my preferred strategy would be to a new
 > mach-nocrap directory with a documented set of rules (to be adapted when
 > necessary):
 >
 > * Strictly no crap
->  * No board files
->  * No hardcoded memory maps
->  * No lists of interrupts and GPIOs
+> ?* No board files
+> ?* No hardcoded memory maps
+> ?* No lists of interrupts and GPIOs
 > * All infrastructure added must be portable to all ARMv7 based SoCs.
->  (ARMv6 can be added later)
+> ?(ARMv6 can be added later)
 > * 64 bit safe code only.
 > * SMP safe code only.
 > * All board specific information must come from a device tree and
->  be run-time detected.
+> ?be run-time detected.
 > * Must use the same device drivers as existing platforms
 > * Should share platform drivers (interrupt controller, gpio, timer, ...)
->  with existing platforms where appropriate.
+> ?with existing platforms where appropriate.
 > * Code quality takes priority over stability in mach-nocrap, but must not
->  break other platforms.
+> ?break other platforms.
 >
 > Until we have something working there, I think we should still generally
 > allow new code to the existing platforms, and even new platforms to be
@@ -121,11 +121,11 @@ patches.
 > Once the mach-nocrap approach has turned into something usable, we can
 > proceed on three fronts:
 > 1. delete actively maintained boards from the other platforms once they
->   are no longer needed there
+> ? are no longer needed there
 > 2. generalize concepts from mach-nocrap by applying them to all boards,
->   similar to the cleanup work that people have always been doing.
+> ? similar to the cleanup work that people have always been doing.
 > 3. gradually make the rules for adding new code in other platforms stricter,
->   up to the point where they are bugfix only.
+> ? up to the point where they are bugfix only.
 >
 >> If companies do not 'bother to push upstream', then management will eventually
 >> notice negative economic consequences:
@@ -136,13 +136,9 @@ patches.
 > are actually understanding this nowadays, and that is exactly the reason
 > why we see so much code getting pushed in.
 >
->        Arnd
+> ? ? ? ?Arnd
 >
 > _______________________________________________
 > linux-arm-kernel mailing list
-> linux-arm-kernel@lists.infradead.org
+> linux-arm-kernel at lists.infradead.org
 > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
---
-To unsubscribe from this list: send the line "unsubscribe linux-omap" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff --git a/a/content_digest b/N1/content_digest
index 42113bc..c582e60 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,32 +2,19 @@
  "ref\08ya39m2mv65.fsf@huya.qualcomm.com\0"
  "ref\020110401074519.GC7594@elte.hu\0"
  "ref\0201104011554.07924.arnd@arndb.de\0"
- "From\0Barry Song <21cnbao@gmail.com>\0"
- "Subject\0Re: [GIT PULL] omap changes for v2.6.39 merge window\0"
+ "From\021cnbao@gmail.com (Barry Song)\0"
+ "Subject\0[GIT PULL] omap changes for v2.6.39 merge window\0"
  "Date\0Tue, 5 Apr 2011 23:11:15 -0700\0"
- "To\0Arnd Bergmann <arnd@arndb.de>\0"
- "Cc\0Ingo Molnar <mingo@elte.hu>"
-  david@lang.hm
-  Russell King - ARM Linux <linux@arm.linux.org.uk>
-  Nicolas Pitre <nico@fluxnic.net>
-  Tony Lindgren <tony@atomide.com>
-  Catalin Marinas <catalin.marinas@arm.com>
-  lkml <linux-kernel@vger.kernel.org>
-  H. Peter Anvin <hpa@zytor.com>
-  David Brown <davidb@codeaurora.org>
-  linux-omap@vger.kernel.org
-  Linus Torvalds <torvalds@linux-foundation.org>
-  Thomas Gleixner <tglx@linutronix.de>
- " linux-arm-kernel@lists.infradead.org\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "2011/4/1 Arnd Bergmann <arnd@arndb.de>:\n"
  "> On Friday 01 April 2011, Ingo Molnar wrote:\n"
  ">> IMO the right answer is what Linus and Thomas outlined:\n"
  ">>\n"
- ">> \302\240 \302\2401) provide a small number of clean examples and clean abstractions\n"
- ">> \302\240 \302\2402) to not pull new crap from that point on\n"
- ">> \302\240 \302\2403) do this gradually but consistently\n"
+ ">> ? ?1) provide a small number of clean examples and clean abstractions\n"
+ ">> ? ?2) to not pull new crap from that point on\n"
+ ">> ? ?3) do this gradually but consistently\n"
  ">>\n"
  ">> I.e. make all your requirements technical and actionable - avoid sweeping,\n"
  ">> impossible to meet requirements. Do not require people to clean up all of the\n"
@@ -55,16 +42,16 @@
  ">\n"
  "> 1. The core arch code is not a problem (Russell does a great job here)\n"
  "> 2. The platform specific code contains a lot of crap that doesn't belong there\n"
- "> \302\240 (not enough reviewers to push back on crap)\n"
+ "> ? (not enough reviewers to push back on crap)\n"
  "> 3. The amount of crap in platform specfic files is growing exponentially,\n"
- "> \302\240 despite the best efforts of a handful of people to clean it up.\n"
+ "> ? despite the best efforts of a handful of people to clean it up.\n"
  "> 4. Having one source file per board does not scale any more.\n"
  "> 5. Discoverable hardware would solve this, but is not going to happen\n"
- "> \302\240 in practice.\n"
+ "> ? in practice.\n"
  "> 6. Board firmware would not solve this and is usually not present.\n"
  "> 7. Boot loaders can not be trusted to pass valid information\n"
  "> 8. Device tree blobs can solve a lot of the problems, and nobody has\n"
- "> \302\240 come up with a better solution.\n"
+ "> ? come up with a better solution.\n"
  "\n"
  "ARM BSP is still blasting! we are planning to merge our new ARM\n"
  "cortex-a9 SoC into kernel. So I am just wondering whether traditional\n"
@@ -103,38 +90,38 @@
  "patches.\n"
  "\n"
  "> 9. All interesting work is going into a handful of platforms, all of which\n"
- "> \302\240 are ARMv7 based.\n"
+ "> ? are ARMv7 based.\n"
  "> 10. We do not want to discontinue support for old boards that work fine.\n"
  "> 11. Massive changes to existing platforms would cause massive breakage.\n"
  "> 12. Supporting many different boards with a single kernel binary is a\n"
- "> \302\240 \302\240useful goal.\n"
+ "> ? ?useful goal.\n"
  "> 13. Infrastructure code should be cross-platform, not duplicated across\n"
- "> \302\240 \302\240platforms.\n"
+ "> ? ?platforms.\n"
  "> 14. 32 bit ARM is hitting the wall in the next years (Cortex-A15 is\n"
- "> \302\240 \302\240actually adding PAE support, which has failed to solve this on\n"
- "> \302\240 \302\240other architectures).\n"
+ "> ? ?actually adding PAE support, which has failed to solve this on\n"
+ "> ? ?other architectures).\n"
  "> 15. We need to solve the platform problem before 64 bit support comes\n"
- "> \302\240 \302\240and adds another dimension to the complexity.\n"
+ "> ? ?and adds another dimension to the complexity.\n"
  ">\n"
  "> Based on these assumptions, my preferred strategy would be to a new\n"
  "> mach-nocrap directory with a documented set of rules (to be adapted when\n"
  "> necessary):\n"
  ">\n"
  "> * Strictly no crap\n"
- "> \302\240* No board files\n"
- "> \302\240* No hardcoded memory maps\n"
- "> \302\240* No lists of interrupts and GPIOs\n"
+ "> ?* No board files\n"
+ "> ?* No hardcoded memory maps\n"
+ "> ?* No lists of interrupts and GPIOs\n"
  "> * All infrastructure added must be portable to all ARMv7 based SoCs.\n"
- "> \302\240(ARMv6 can be added later)\n"
+ "> ?(ARMv6 can be added later)\n"
  "> * 64 bit safe code only.\n"
  "> * SMP safe code only.\n"
  "> * All board specific information must come from a device tree and\n"
- "> \302\240be run-time detected.\n"
+ "> ?be run-time detected.\n"
  "> * Must use the same device drivers as existing platforms\n"
  "> * Should share platform drivers (interrupt controller, gpio, timer, ...)\n"
- "> \302\240with existing platforms where appropriate.\n"
+ "> ?with existing platforms where appropriate.\n"
  "> * Code quality takes priority over stability in mach-nocrap, but must not\n"
- "> \302\240break other platforms.\n"
+ "> ?break other platforms.\n"
  ">\n"
  "> Until we have something working there, I think we should still generally\n"
  "> allow new code to the existing platforms, and even new platforms to be\n"
@@ -144,11 +131,11 @@
  "> Once the mach-nocrap approach has turned into something usable, we can\n"
  "> proceed on three fronts:\n"
  "> 1. delete actively maintained boards from the other platforms once they\n"
- "> \302\240 are no longer needed there\n"
+ "> ? are no longer needed there\n"
  "> 2. generalize concepts from mach-nocrap by applying them to all boards,\n"
- "> \302\240 similar to the cleanup work that people have always been doing.\n"
+ "> ? similar to the cleanup work that people have always been doing.\n"
  "> 3. gradually make the rules for adding new code in other platforms stricter,\n"
- "> \302\240 up to the point where they are bugfix only.\n"
+ "> ? up to the point where they are bugfix only.\n"
  ">\n"
  ">> If companies do not 'bother to push upstream', then management will eventually\n"
  ">> notice negative economic consequences:\n"
@@ -159,15 +146,11 @@
  "> are actually understanding this nowadays, and that is exactly the reason\n"
  "> why we see so much code getting pushed in.\n"
  ">\n"
- "> \302\240 \302\240 \302\240 \302\240Arnd\n"
+ "> ? ? ? ?Arnd\n"
  ">\n"
  "> _______________________________________________\n"
  "> linux-arm-kernel mailing list\n"
- "> linux-arm-kernel@lists.infradead.org\n"
- "> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel\n"
- "--\n"
- "To unsubscribe from this list: send the line \"unsubscribe linux-omap\" in\n"
- "the body of a message to majordomo@vger.kernel.org\n"
- More majordomo info at  http://vger.kernel.org/majordomo-info.html
+ "> linux-arm-kernel at lists.infradead.org\n"
+ > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 
-56230d9c97c3ab6a91f08f71a15ca7a2fb0e1a19a32d4bbdf45356b32b53158b
+e8d520ca143803122fbf775c1a5bddcf4d56425eee141ef9db6e9d1264f8f0be
