Linux Embedded

• Thread Index

• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Greg Ungerer <gerg@xxxxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: "Parag Warudkar" <parag.lkml@xxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Adrian Bunk <bunk@xxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [PATCH] 2.6.27-rc4-git3: make section names compatible with -ffunction-sections -fdata-sections
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] 2.6.27-rc4-git3: make section names compatible with -ffunction-sections -fdata-sections
  • From: Daniel Walker <dwalker@xxxxxxxxxx>
• Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [RFC] Remove more code when IP_MULTICAST=n
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [RFC] Remove more code when IP_MULTICAST=n
  • From: Paul Mundt <lethal@xxxxxxxxxxxx>
• Re: [RFC] Remove more code when IP_MULTICAST=n
  • From: "Mike Frysinger" <vapier.adi@xxxxxxxxx>
• Re: [RFC] Remove more code when IP_MULTICAST=n
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Greg Ungerer <gerg@xxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Carsten Otte <cotte@xxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Greg Ungerer <gerg@xxxxxxxxxxxx>
• [PATCH] 2.6.27-rc4-git3: make section names compatible with -ffunction-sections -fdata-sections
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: embedded rootfs utility
  • From: Behan Webster <behanw@xxxxxxxxxxxxxxx>
• Re: [PATCH 07/10] AXFS: axfs_bdev.c
  • From: "MinChan Kim" <minchan.kim@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Will Marone <wjmarone@xxxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [PATCH 03/10] AXFS: axfs.h
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: Jörn Engel <joern@xxxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 07/10] AXFS: axfs_bdev.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• mkfs.axfs
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: [PATCH 07/10] AXFS: axfs_bdev.c
  • From: Bernhard Reutner-Fischer <rep.dot.nop@xxxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: Bernhard Reutner-Fischer <rep.dot.nop@xxxxxxxxx>
• Re: [PATCH 03/10] AXFS: axfs.h
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: [PATCH 03/10] AXFS: axfs.h
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: Carsten Otte <cotte@xxxxxxxxxx>
• Re: Adding a new platform
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• Re: Adding a new platform
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: kernel dump solutions
  • From: Josh Boyer <jwboyer@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Nick Piggin <nickpiggin@xxxxxxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Nick Piggin <nickpiggin@xxxxxxxxxxxx>
• Re: kernel dump solutions
  • From: "Randy MacLeod" <rwmacleod@xxxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Greg Ungerer <gerg@xxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Greg Ungerer <gerg@xxxxxxxxxxxx>
• Re: [PATCH 03/10] AXFS: axfs.h
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 03/10] AXFS: axfs.h
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 03/10] AXFS: axfs.h
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 10/10] AXFS: axfs_uncompress.c
  • From: Sven Wegener <sven.wegener@xxxxxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: Sven Wegener <sven.wegener@xxxxxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 10/10] AXFS: axfs_uncompress.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 10/10] AXFS: axfs_uncompress.c
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Leon Woestenberg" <leon.woestenberg@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 02/10] AXFS: Kconfig and Makefiles
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Jared Hulbert" <jaredeh@xxxxxxxxx>
• Re: [PATCH 03/10] AXFS: axfs.h
  • From: Daniel Walker <dwalker@xxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 10/10] AXFS: axfs_uncompress.c
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: [PATCH 03/10] AXFS: axfs.h
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 10/10] AXFS: axfs_uncompress.c
  • From: Artem Bityutskiy <dedekind@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 03/10] AXFS: axfs.h
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: Sven Wegener <sven.wegener@xxxxxxxxxxx>
• Re: [PATCH 02/10] AXFS: Kconfig and Makefiles
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Nick Piggin <nickpiggin@xxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Carsten Otte <cotte@xxxxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: Carsten Otte <cotte@xxxxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: Adding a new platform
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: Adding a new platform
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: Sven Wegener <sven.wegener@xxxxxxxxxxx>
• Re: [PATCH 10/10] AXFS: axfs_uncompress.c
  • From: Sven Wegener <sven.wegener@xxxxxxxxxxx>
• Re: [PATCH 06/10] AXFS: axfs_super.c
  • From: Carsten Otte <cotte@xxxxxxxxxx>
• Re: Adding a new platform
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: [PATCH 05/10] AXFS: axfs_profiling.c
  • From: Carsten Otte <cotte@xxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [PATCH 04/10] AXFS: axfs_inode.c
  • From: Carsten Otte <cotte@xxxxxxxxxx>
• Re: [PATCH 03/10] AXFS: axfs.h
  • From: Carsten Otte <cotte@xxxxxxxxxx>
• Re: [PATCH 01/10] AXFS: exporting xip_file_fault() for use with AXFS
  • From: Carsten Otte <cotte@xxxxxxxxxx>
• Re: [PATCH 01/10] AXFS: exporting xip_file_fault() for use with AXFS
  • From: Paulius Zaleckas <paulius.zaleckas@xxxxxxxxxxxx>
• Re: [PATCH 01/10] AXFS: exporting xip_file_fault() for use with AXFS
  • From: Paulius Zaleckas <paulius.zaleckas@xxxxxxxxxxxx>
• Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: "Frans Meulenbroeks" <fransmeulenbroeks@xxxxxxxxx>
• [PATCH 10/10] AXFS: axfs_uncompress.c
  • From: Jared Hulbert <jaredeh@xxxxxxxxx>
• [PATCH 09/10] AXFS: axfs_uml.c
  • From: Jared Hulbert <jaredeh@xxxxxxxxx>
• [PATCH 08/10] AXFS: axfs_mtd.c
  • From: Jared Hulbert <jaredeh@xxxxxxxxx>
• [PATCH 07/10] AXFS: axfs_bdev.c
  • From: Jared Hulbert <jaredeh@xxxxxxxxx>
• [PATCH 06/10] AXFS: axfs_super.c
  • From: Jared Hulbert <jaredeh@xxxxxxxxx>
• [PATCH 05/10] AXFS: axfs_profiling.c
  • From: Jared Hulbert <jaredeh@xxxxxxxxx>
• [PATCH 04/10] AXFS: axfs_inode.c
  • From: Jared Hulbert <jaredeh@xxxxxxxxx>
• [PATCH 03/10] AXFS: axfs.h
  • From: Jared Hulbert <jaredeh@xxxxxxxxx>
• [PATCH 02/10] AXFS: Kconfig and Makefiles
  • From: Jared Hulbert <jaredeh@xxxxxxxxx>
• [PATCH 01/10] AXFS: exporting xip_file_fault() for use with AXFS
  • From: Jared Hulbert <jaredeh@xxxxxxxxx>
• [PATCH 00/10] AXFS: Advanced XIP filesystem
  • From: Jared Hulbert <jaredeh@xxxxxxxxx>
• Re: Adding a new platform
  • From: Charles Manning <manningc2@xxxxxxxxxxxxx>
• Re: Adding a new platform
  • From: vb <vb@xxxxxxxx>
• Re: Module init for compiled in vs loaded modules
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: Adding a new platform
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: Adding a new platform
  • From: vb <vb@xxxxxxxx>
• Re: Adding a new platform
  • From: Paul Mundt <lethal@xxxxxxxxxxxx>
• Re: Adding a new platform
  • From: "Paul Gortmaker" <paul.gortmaker@xxxxxxxxx>
• Re: Adding a new platform
  • From: vb <vb@xxxxxxxx>
• Re: New elinux.org mailing lists
  • From: Bill Traynor <wmat@xxxxxxx>
• Re: Adding a new platform
  • From: "Paul Gortmaker" <paul.gortmaker@xxxxxxxxx>
• Re: New elinux.org mailing lists
  • From: David Anders <dave123_aml@xxxxxxxxx>
• New elinux.org mailing lists
  • From: "Bill Traynor" <wmat@xxxxxxx>
• Re: Adding a new platform
  • From: Ralf Baechle <ralf@xxxxxxxxxxxxxx>
• Adding a new platform
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: Module init for compiled in vs loaded modules
  • From: Fundu <fundu_1999@xxxxxxxxx>
• Re: Module init for compiled in vs loaded modules
  • From: T Ziomek <ctz001@xxxxxxxxxxxxx>
• Re: [RFC] Remove more code when IP_MULTICAST=n
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• [RFC] Remove more code when IP_MULTICAST=n
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: Module init for compiled in vs loaded modules
  • From: "Amol Lad" <amol.lad@xxxxxxxxx>
• Module init for compiled in vs loaded modules
  • From: Fundu <fundu_1999@xxxxxxxxx>
• Re: embedded rootfs utility
  • From: "Grant Likely" <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH] [x86] Move cmpxchg fallbacks to a generic place
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: embedded rootfs utility
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• [PATCH] [x86] Make movsl_mask definition non-CPU specific
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• [PATCH] [x86] Move cmpxchg fallbacks to a generic place
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86 (v2)
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86 (v2)
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: embedded rootfs utility
  • From: Michelle Konzack <linux4michelle@xxxxxxxxxxxxxxx>
• Re: embedded rootfs utility
  • From: Behan Webster <behanw@xxxxxxxxxxxxxxx>
• Re: embedded rootfs utility
  • From: "Grant Likely" <grant.likely@xxxxxxxxxxxx>
• Re: embedded rootfs utility
  • From: Behan Webster <behanw@xxxxxxxxxxxxxxx>
• Re: Flatten device tree & PPC linu
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: embedded rootfs utility
  • From: "Grant Likely" <grant.likely@xxxxxxxxxxxx>
• Re: embedded rootfs utility
  • From: Behan Webster <behanw@xxxxxxxxxxxxxxx>
• Re: Flatten device tree & PPC linu
  • From: "Grant Likely" <grant.likely@xxxxxxxxxxxx>
• Re: embedded rootfs utility
  • From: "Grant Likely" <grant.likely@xxxxxxxxxxxx>
• Flatten device tree & PPC linux
  • From: Fundu <fundu_1999@xxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• kernel dump solutions
  • From: Josh Boyer <jwboyer@xxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: "Grant Likely" <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86 (v2)
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• ppc linux cpu features fixups
  • From: "Mihaela Grigore" <grigore.mihaela@xxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: initrd and uImage
  • From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@xxxxxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: initrd and uImage
  • From: Josh Boyer <jwboyer@xxxxxxxxx>
• Re: initrd and uImage
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code
  • From: Bodo Eggert <7eggert@xxxxxx>
• RE: [PATCH] [RFC] emit-crash-char: Allow diversion of printkoutput for crash logging
  • From: Daniel Walker <dwalker@xxxxxxxxxx>
• RE: [PATCH] [RFC] emit-crash-char: Allow diversion of printkoutput for crash logging
  • From: "Haller, John H \(John\)" <jhaller@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: Daniel Walker <dwalker@xxxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: "Mike Frysinger" <vapier.adi@xxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: Daniel Walker <dwalker@xxxxxxxxxx>
• Perl removal patch for 2.6.26.
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: linux under emulator
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: initrd and uImage
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: "Mike Frysinger" <vapier.adi@xxxxxxxxx>
• Re: embedded rootfs utility
  • From: Behan Webster <behanw@xxxxxxxxxxxxxxx>
• initrd and uImage
  • From: Fundu <fundu_1999@xxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: Daniel Walker <dwalker@xxxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: "Mike Frysinger" <vapier.adi@xxxxxxxxx>
• Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: Daniel Walker <dwalker@xxxxxxxxxx>
• Re: kernel command line from u-boot
  • From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
• OLS 2008 videos
  • From: Michael Opdenacker <michael-lists@xxxxxxxxxxxxxxxxxx>
• [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
• Re: kernel command line from u-boot
  • From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
• Re: kernel command line from u-boot
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: kernel command line from u-boot
  • From: "Amol Lad" <amol.lad@xxxxxxxxx>
• Re: kernel command line from u-boot
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• kernel command line from u-boot
  • From: "Amol Lad" <amol.lad@xxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• Re: [PATCH] bootup: Add built-in kernel command line for x86
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• [PATCH] bootup: Add built-in kernel command line for x86
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Big include file move breaks user mode
  • From: Kumar Gala <galak@xxxxxxxxxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: embedded rootfs utility
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: [patch 1/4] Configure out AIO support
  • From: Bernhard Fischer <rep.dot.nop@xxxxxxxxx>
• Re: [patch 1/4] Configure out AIO support
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [patch 1/4] Configure out AIO support
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: linux under emulator
  • From: "Grant Likely" <grant.likely@xxxxxxxxxxxx>
• linux under emulator
  • From: "Mihaela Grigore" <grigore.mihaela@xxxxxxxxx>
• Re: linux kernel under psim
  • From: Kumar Gala <galak@xxxxxxxxxxxxxxxxxxx>
• Re: Intrusion detection system
  • From: Kumar Gala <galak@xxxxxxxxxxxxxxxxxxx>
• Re: Intrusion detection system
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxxx>
• Re: Intrusion detection system
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxxx>
• Re: Intrusion detection system
  • From: Kumar Gala <galak@xxxxxxxxxxxxxxxxxxx>
• linux kernel under psim
  • From: "Mihaela Grigore" <grigore.mihaela@xxxxxxxxx>
• [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Intrusion detection system
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxxx>
• Re: is it worth separating initrd from initramfs support?
  • From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH 2/6] Container Freezer: Make refrigerator always available
  • From: Matt Helsley <matthltc@xxxxxxxxxx>
• Re: is it worth separating initrd from initramfs support?
  • From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
• Re: is it worth separating initrd from initramfs support?
  • From: "Leon Woestenberg" <leon.woestenberg@xxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• is it worth separating initrd from initramfs support?
  • From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
• Re: [PATCH] embedded: fix vc_translate operator precedence
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [patch 4/4] Configure out IGMP support
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: [patch 4/4] Configure out IGMP support
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [patch 4/4] Configure out IGMP support
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] embedded: fix vc_translate operator precedence
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: [PATCH] embedded: fix vc_translate operator precedence
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [PATCH] embedded: fix vc_translate operator precedence
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
• Re: [PATCH 2/6] Container Freezer: Make refrigerator always available
  • From: "Rafael J. Wysocki" <rjw@xxxxxxx>
• Re: [PATCH 2/6] Container Freezer: Make refrigerator always available
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Ben Nizette <bn@xxxxxxxxxxxxxxx>
• Re: [PATCH 2/6] Container Freezer: Make refrigerator always available
  • From: Matt Helsley <matthltc@xxxxxxxxxx>
• Re: [PATCH 2/6] Container Freezer: Make refrigerator always available
  • From: "Rafael J. Wysocki" <rjw@xxxxxxx>
• Re: conceptual map of the kernel source (Interactive Linux kernel map)
  • From: "Constantine Shulyupin" <const@xxxxxxxxxxxxxxxxx>
• Re: conceptual map of the kernel source (Interactive Linux kernel map)
  • From: "Linus Walleij" <linus.ml.walleij@xxxxxxxxx>
• [PATCH] embedded: fix vc_translate operator precedence
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 4/4] Configure out IGMP support
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/6] Container Freezer: Make refrigerator always available
  • From: Matt Helsley <matthltc@xxxxxxxxxx>
• Re: [PATCH 2/6] Container Freezer: Make refrigerator always available
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: Book about embedded-type device drivers
  • From: Markus Franke <Markus.Franke@xxxxxxxxxxxxxxxxxxxxxxxxx>
• Book about embedded-type device drivers
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: AT91 kernel programming documentation ?
  • From: Stefan Schoenleitner <dev.c0debabe@xxxxxxxxx>
• Re: [patch 1/4] Configure out AIO support
  • From: Bernhard Fischer <rep.dot.nop@xxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features
  • From: Josh Boyer <jwboyer@xxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features
  • From: Ulrich Teichert <krypton@xxxxxxxxxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• conceptual map of the kernel source (Interactive Linux kernel map)
  • From: "Constantine Shulyupin" <const@xxxxxxxxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: Ben Hutchings <bhutchings@xxxxxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch 3/4] Configure out ethtool support
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 1/4] Configure out AIO support
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [patch 1/4] Configure out AIO support
  • From: Bernhard Fischer <rep.dot.nop@xxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [patch 3/4] Configure out ethtool support
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• [patch 2/4] Configure out file locking features
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• [patch 4/4] Configure out IGMP support
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• [patch 1/4] Configure out AIO support
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Uwe Kleine-König <Uwe.Kleine-Koenig@xxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: embedded rootfs utility
  • From: Behan Webster <behanw@xxxxxxxxxxxxxxx>
• Re: embedded rootfs utility
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: embedded rootfs utility
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: AT91 kernel programming documentation ?
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Bernd Petrovitsch <bernd@xxxxxxxxx>
• AT91 kernel programming documentation ?
  • From: Stefan Schoenleitner <dev.c0debabe@xxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Bernd Petrovitsch <bernd@xxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: "Bart Van Assche" <bart.vanassche@xxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: "Bart Van Assche" <bart.vanassche@xxxxxxxxx>
• embedded rootfs utility
  • From: Behan Webster <behanw@xxxxxxxxxxxxxxx>
• RE: prevalence of C++ in embedded linux?
  • From: "Leisner, Martin" <Martin.Leisner@xxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• Re: [patch 2/4] Configure out file locking features
  • From: Matthew Wilcox <matthew@xxxxxx>
• Re: [patch 1/4] Configure out AIO support
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: "Richard Danter" <radanter@xxxxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Bernd Petrovitsch <bernd@xxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Bernd Petrovitsch <bernd@xxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Alexander Neundorf <neundorf@xxxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: "Bart Van Assche" <bart.vanassche@xxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Alexander Neundorf <neundorf@xxxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: "Roberto A. Foglietta" <roberto.foglietta@xxxxxxxxx>
• Re: [ANNOUNCE] udev 125 release
  • From: md@xxxxxxxx (Marco d'Itri)
• Re: [ANNOUNCE] udev 125 release
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Ben Nizette <bn@xxxxxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Matthias Kaehlcke <matthias@xxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Domenico Andreoli <cavokz@xxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: prevalence of C++ in embedded linux?
  • From: Chris <chris@xxxxxxxxxx>
• prevalence of C++ in embedded linux?
  • From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
• Re: testing ethernet device with external loopback
  • From: David Anders <dave123_aml@xxxxxxxxx>
• Re: testing ethernet device with external loopback
  • From: James Chapman <jchapman@xxxxxxxxxxx>
• testing ethernet device with external loopback
  • From: Sebastien Fauris <titelive72@xxxxxxxxx>
• RE: Porting tips
  • From: "Turquette, Mike" <mturquette@xxxxxx>
• [ANN] Device Tree Mailing List
  • From: Hugh Blemings <hugh@xxxxxxxxxxxx>
• Porting tips
  • From: Shaz <shazalive@xxxxxxxxx>
• Re: Useful IRC channels
  • From: Shaz <shazalive@xxxxxxxxx>
• Re: Useful IRC channels
  • From: "Bill Traynor" <wmat@xxxxxxx>
• Re: [PATCH] (updated, rolled up) make section names compatible with -ffunction-sections -fdata-sections
  • From: Jesper Nilsson <jesper.nilsson@xxxxxxxx>
• Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
  • From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@xxxxxxxxxxxx>
• Re: Useful IRC channels
  • From: Samuel Robb <sam@xxxxxxxxxxxxxxxxxxxxxxx>
• Re: Useful IRC channels
  • From: Wookey <wookey@xxxxxxxxxxxx>
• Re: Useful IRC channels
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Useful IRC channels
  • From: Shaz <shazalive@xxxxxxxxx>
• Kernel not taking command line arguements from bootloader
  • From: "sourya roy" <souryaroy@xxxxxxxxx>
• Re: UIO not working on ppc405 onchip registers
  • From: super.firetwister@xxxxxxxxxxxxxx
• Re: UIO not working on ppc405 onchip registers
  • From: Ben Nizette <bn@xxxxxxxxxxxxxxx>
• Re: UIO not working on ppc405 onchip registers
  • From: super.firetwister@xxxxxxxxxxxxxx
• Re: UIO not working on ppc405 onchip registers
  • From: super.firetwister@xxxxxxxxxxxxxx
• Re: UIO not working on ppc405 onchip registers
  • From: Ben Nizette <bn@xxxxxxxxxxxxxxx>
• Re: UIO not working on ppc405 onchip registers
  • From: Uwe Kleine-König <Uwe.Kleine-Koenig@xxxxxxxx>
• UIO not working on ppc405 onchip registers
  • From: Markus Brunner <super.firetwister@xxxxxxxxxxxxxx>
• Re: RFC: prevent auto binding for some platform devices
  • From: Uwe Kleine-König <Uwe.Kleine-Koenig@xxxxxxxx>
• Re: RFC: prevent auto binding for some platform devices
  • From: Ben Nizette <bn@xxxxxxxxxxxxxxx>
• Re: RFC: prevent auto binding for some platform devices
  • From: "Alexey Zaytsev" <alexey.zaytsev@xxxxxxxxx>
• Re: prevent auto binding for some platform devices
  • From: Uwe Kleine-König <Uwe.Kleine-Koenig@xxxxxxxx>
• Re: RFC: prevent auto binding for some platform devices
  • From: "Alexey Zaytsev" <alexey.zaytsev@xxxxxxxxx>
• RE: prevent auto binding for some platform devices
  • From: "Dasgupta, Romit" <romit@xxxxxx>
• RFC: prevent auto binding for some platform devices
  • From: Uwe Kleine-König <Uwe.Kleine-Koenig@xxxxxxxx>
• Re: [PATCH] (updated, rolled up) make section names compatible with -ffunction-sections -fdata-sections
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH] (updated, rolled up) make section names compatible with -ffunction-sections -fdata-sections
  • From: Greg Ungerer <gerg@xxxxxxxxxxxx>
• Re: [PATCH] (updated, rolled up) make section names compatible with -ffunction-sections -fdata-sections
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH] (updated, rolled up) make section names compatible with -ffunction-sections -fdata-sections
  • From: Ralf Baechle <ralf@xxxxxxxxxxxxxx>
• Re: [PATCH] (updated, rolled up) make section names compatible with -ffunction-sections -fdata-sections
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] (updated, rolled up) make section names compatible with -ffunction-sections -fdata-sections
  • From: "Mike Frysinger" <vapier.adi@xxxxxxxxx>
• [PATCH] (updated, rolled up) make section names compatible with -ffunction-sections -fdata-sections
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
  • From: "Andrés Calderón" <andres.calderon@xxxxxxxxxx>
• Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
  • From: Michelle Konzack <linux4michelle@xxxxxxxxxxxxxxx>
• Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
  • From: Michelle Konzack <linux4michelle@xxxxxxxxxxxxxxx>
• Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
  • From: Michelle Konzack <linux4michelle@xxxxxxxxxxxxxxx>
• Re: building Rootfs
  • From: Marek Skuczynski <mareksk@xxxxxxxxxxx>
• Re: building Rootfs
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• Re: building Rootfs
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: building Rootfs
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: building Rootfs
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: building Rootfs
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: building Rootfs
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: building Rootfs
  • From: "Linus Walleij" <linus.ml.walleij@xxxxxxxxx>
• Re: building Rootfs
  • From: "Linus Walleij" <linus.ml.walleij@xxxxxxxxx>
• Re: building Rootfs
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: building Rootfs
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• RE: building Rootfs
  • From: "Haller, John H \(John\)" <jhaller@xxxxxxxxxxxxxxxxxx>
• Re: building Rootfs
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: building Rootfs
  • From: "Linus Walleij" <linus.ml.walleij@xxxxxxxxx>
• Re: Atmel AT91SAM7S and AT91SAM7A3
  • From: "Richard Genoud" <richard.genoud@xxxxxxxxx>
• Re: Incompatible CFLAGS for kernel module
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: Incompatible CFLAGS for kernel module
  • From: Shaz <shazalive@xxxxxxxxx>
• Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
  • From: Stefan Schoenleitner <dev.c0debabe@xxxxxxxxx>
• Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
  • From: Stefan Schoenleitner <dev.c0debabe@xxxxxxxxx>
• Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
  • From: Stefan Schoenleitner <dev.c0debabe@xxxxxxxxx>
• Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
  • From: Stefan Schoenleitner <dev.c0debabe@xxxxxxxxx>
• Re: Incompatible CFLAGS for kernel module
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: Incompatible CFLAGS for kernel module
  • From: Shaz <shazalive@xxxxxxxxx>
• Re: Incompatible CFLAGS for kernel module
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Incompatible CFLAGS for kernel module
  • From: Shaz <shazalive@xxxxxxxxx>
• Re: [PATCH v4 5/6] dmaengine: Driver for the Synopsys DesignWare DMA controller
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• RE: [PATCH v4 5/6] dmaengine: Driver for the Synopsys DesignWare DMA controller
  • From: "Sosnowski, Maciej" <maciej.sosnowski@xxxxxxxxx>
• Re: [PATCH v4 0/6] dmaengine/mmc: DMA slave interface and two new drivers
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: dmaengine skip unmap (was: Re: [PATCH v4 5/6] dmaengine: Driver for the Synopsys DesignWare DMA controller)
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: [PATCH v4 0/6] dmaengine/mmc: DMA slave interface and two new drivers
  • From: "Dan Williams" <dan.j.williams@xxxxxxxxx>
• dmaengine skip unmap (was: Re: [PATCH v4 5/6] dmaengine: Driver for the Synopsys DesignWare DMA controller)
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 21/23] make section names compatible with -ffunction-sections -fdata-sections: v850
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• Re: [PATCH 21/23] make section names compatible with -ffunction-sections -fdata-sections: v850
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• Re: [PATCH 21/23] make section names compatible with -ffunction-sections -fdata-sections: v850
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 21/23] make section names compatible with -ffunction-sections -fdata-sections: v850
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• Re: [PATCH 21/23] make section names compatible with -ffunction-sections -fdata-sections: v850
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 21/23] make section names compatible with -ffunction-sections -fdata-sections: v850
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 22/23] make section names compatible with -ffunction-sections -fdata-sections: x86
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [PATCH 16/23] make section names compatible with -ffunction-sections -fdata-sections: ppc
  • From: Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [PATCH v4 2/6] dmaengine: Add dma_chan_is_in_use() function
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: [PATCH v4 2/6] dmaengine: Add dma_chan_is_in_use() function
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: [PATCH 3/23] make section names compatible with -ffunction-sections -fdata-sections: arm
  • From: "Roberto A. Foglietta" <roberto.foglietta@xxxxxxxxx>
• Re: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 5/23] make section names compatible with -ffunction-sections -fdata-sections: blackfin
  • From: "Mike Frysinger" <vapier.adi@xxxxxxxxx>
• Re: [PATCH v4 2/6] dmaengine: Add dma_chan_is_in_use() function
  • From: "Dan Williams" <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
  • From: Eduard - Gabriel Munteanu <eduard.munteanu@xxxxxxxxxxx>
• Re: selecting initramfs support without initrd?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [PATCH v4 2/6] dmaengine: Add dma_chan_is_in_use() function
  • From: "Dan Williams" <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 5/23] make section names compatible with -ffunction-sections -fdata-sections: blackfin
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
  • From: Valdis.Kletnieks@xxxxxx
• Re: [PATCH 5/23] make section names compatible with -ffunction-sections -fdata-sections: blackfin
  • From: "Mike Frysinger" <vapier.adi@xxxxxxxxx>
• [PATCH 23/23] make section names compatible with -ffunction-sections -fdata-sections: xtensa
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 22/23] make section names compatible with -ffunction-sections -fdata-sections: x86
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 21/23] make section names compatible with -ffunction-sections -fdata-sections: v850
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 20/23] make section names compatible with -ffunction-sections -fdata-sections: um
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 19/23] make section names compatible with -ffunction-sections -fdata-sections: sparc
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 18/23] make section names compatible with -ffunction-sections -fdata-sections: sh
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 17/23] make section names compatible with -ffunction-sections -fdata-sections: s390
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 16/23] make section names compatible with -ffunction-sections -fdata-sections: ppc
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 15/23] make section names compatible with -ffunction-sections -fdata-sections: powerpc
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 13/23] make section names compatible with -ffunction-sections -fdata-sections: mn10300
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 12/23] make section names compatible with -ffunction-sections -fdata-sections: m68k
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 11/23] make section names compatible with -ffunction-sections -fdata-sections: mips
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 10/23] make section names compatible with -ffunction-sections -fdata-sections: m32r
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 9/23] make section names compatible with -ffunction-sections -fdata-sections: ia64
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 8/23] make section names compatible with -ffunction-sections -fdata-sections: h8300
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 7/23] make section names compatible with -ffunction-sections -fdata-sections: frv
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 6/23] make section names compatible with -ffunction-sections -fdata-sections: cris
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 5/23] make section names compatible with -ffunction-sections -fdata-sections: blackfin
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 4/23] make section names compatible with -ffunction-sections -fdata-sections: avr
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 3/23] make section names compatible with -ffunction-sections -fdata-sections: arm
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 2/23] make section names compatible with -ffunction-sections -fdata-sections: alpha
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: Atmel AT91SAM7S and AT91SAM7A3
  • From: Michelle Konzack <linux4michelle@xxxxxxxxxxxxxxx>
• Re: Dump Management
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Gilad Ben-Yossef <gilad@xxxxxxxxxxxxxxx>
• Re: Dump Management
  • From: Gilad Ben-Yossef <gilad@xxxxxxxxxxxxxxx>
• RE: [PATCH v4 3/6] dmaengine: Add slave DMA interface
  • From: "Sosnowski, Maciej" <maciej.sosnowski@xxxxxxxxx>
• RE: [PATCH v4 2/6] dmaengine: Add dma_chan_is_in_use() function
  • From: "Sosnowski, Maciej" <maciej.sosnowski@xxxxxxxxx>
• RE: [PATCH v4 1/6] dmaengine: Add dma_client parameter to device_alloc_chan_resources
  • From: "Sosnowski, Maciej" <maciej.sosnowski@xxxxxxxxx>
• Dump Management
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxxx>
• Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
  • From: Pierre Ossman <drzeus-list@xxxxxxxxx>
• Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
  • From: Pierre Ossman <drzeus-list@xxxxxxxxx>
• Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
  • From: Pierre Ossman <drzeus-list@xxxxxxxxx>
• Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: [PATCH v4 3/6] dmaengine: Add slave DMA interface
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: Atmel AT91SAM7S and AT91SAM7A3
  • From: Ben Nizette <bn@xxxxxxxxxxxxxxx>
• Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH] add diffconfig utility (v2)
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
  • From: Pierre Ossman <drzeus-list@xxxxxxxxx>
• Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users
  • From: "Dan Williams" <dan.j.williams@xxxxxxxxx>
• Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users
  • From: David Brownell <david-b@xxxxxxxxxxx>
• Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Atmel AT91SAM7S and AT91SAM7A3
  • From: Michelle Konzack <linux4michelle@xxxxxxxxxxxxxxx>
• Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users
  • From: David Brownell <david-b@xxxxxxxxxxx>
• Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users
  • From: David Brownell <david-b@xxxxxxxxxxx>
• Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• [PATCH v4 3/6] dmaengine: Add slave DMA interface
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• [PATCH v4 1/6] dmaengine: Add dma_client parameter to device_alloc_chan_resources
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• [PATCH v4 5/6] dmaengine: Driver for the Synopsys DesignWare DMA controller
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• [PATCH v4 2/6] dmaengine: Add dma_chan_is_in_use() function
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• [PATCH v4 0/6] dmaengine/mmc: DMA slave interface and two new drivers
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: [PATCH v4 3/6] dmaengine: Add slave DMA interface
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users
  • From: Haavard Skinnemoen <haavard.skinnemoen@xxxxxxxxx>
• Re: selecting initramfs support without initrd?
  • From: "Leon Woestenberg" <leon.woestenberg@xxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: James Chapman <jchapman@xxxxxxxxxxx>
• Re: Firmware Linux (was Re: Cross Compiler and loads of issues)
  • From: Rob Landley <rob@xxxxxxxxxxx>
• selecting initramfs support without initrd?
  • From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
• [PATCH] add diffconfig utility (v2)
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Gilad Ben-Yossef <gilad@xxxxxxxxxxxxxxx>
• Re: Kernel boot problem on IXP422 Rev. A
  • From: Greg Ungerer <gerg@xxxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Kernel boot problem on IXP422 Rev. A
  • From: Marcus Tangermann <marcus.tangermann@xxxxxx>
• Video playback on osk with linux-2.6.18
  • From: "mohammed shareef" <mdshareef@xxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Nicolas Pitre <nico@xxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: "Amol Lad" <amol.lad@xxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Johannes Stezenbach <js@xxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Gilad Ben-Yossef <gilad@xxxxxxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Johannes Stezenbach <js@xxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Josh Boyer <jwboyer@xxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Jörn Engel <joern@xxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Jörn Engel <joern@xxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Jim Freeman <jfree@xxxxxxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: Jörn Engel <joern@xxxxxxxxx>
• Re: Recommendation for activating a deferred module init in the kernel
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Recommendation for activating a deferred module init in the kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Alexander Neundorf <neundorf@xxxxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Alexander Neundorf <neundorf@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: cross-compiling alternatives
  • From: Bernhard Fischer <rep.dot.nop@xxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Bernhard Fischer <rep.dot.nop@xxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Bernhard Fischer <rep.dot.nop@xxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: cross-compiling alternatives
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Alexander Neundorf <neundorf@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives
  • From: Bernd Petrovitsch <bernd@xxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives
  • From: Alexander Neundorf <neundorf@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives
  • From: Bernd Petrovitsch <bernd@xxxxxxxxx>
• Re: cross-compiling alternatives
  • From: Bernd Petrovitsch <bernd@xxxxxxxxx>
• Re: cross-compiling alternatives
  • From: Bernd Petrovitsch <bernd@xxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Alexander Neundorf <neundorf@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Alexander Neundorf <neundorf@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Alexander Neundorf <neundorf@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Alexander Neundorf <neundorf@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: Firmware Linux (was Re: Cross Compiler and loads of issues)
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: cross-compiling alternatives
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Enrico Weigelt <weigelt@xxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: Kernel boot problem on IXP422 Rev. A
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: Not as much ccache win as I expected
  • From: Jörn Engel <joern@xxxxxxxxx>
• Re: about size optimizations (Re: Not as much ccache win as I expected)
  • From: "Oleg Verych" <olecom@xxxxxxxxx>
• Re: about size optimizations (Re: Not as much ccache win as I expected)
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: "Leon Woestenberg" <leon.woestenberg@xxxxxxxxx>
• Re: modules.dep and depmod.pl
  • From: "Linus Walleij" <linus.ml.walleij@xxxxxxxxx>
• Re: modules.dep and depmod.pl
  • From: "Linus Walleij" <linus.ml.walleij@xxxxxxxxx>
• Re: modules.dep and depmod.pl
  • From: Bernhard Fischer <rep.dot.nop@xxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: about size optimizations (Re: Not as much ccache win as I expected)
  • From: "Oleg Verych" <olecom@xxxxxxxxx>
• Re: about size optimizations (Re: Not as much ccache win as I expected)
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: about size optimizations (Re: Not as much ccache win as I expected)
  • From: "Oleg Verych" <olecom@xxxxxxxxx>
• Re: about size optimizations (Re: Not as much ccache win as I expected)
  • From: Adrian Bunk <bunk@xxxxxxxxxx>
• Re: Cross Compiler and loads of issues
  • From: Shaz <shazalive@xxxxxxxxx>
• Re: modules.dep and depmod.pl
  • From: Matthieu castet <castet.matthieu@xxxxxxx>
• Re: about size optimizations (Re: Not as much ccache win as I expected)
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: Kernel boot problem on IXP422 Rev. A
  • From: Greg Ungerer <gerg@xxxxxxxxxxxx>
• Re: Cross Compiler and loads of issues
  • From: Greg Ungerer <gerg@xxxxxxxxxxxx>
• Re: Cross Compiler and loads of issues
  • From: Greg Ungerer <gerg@xxxxxxxxxxxx>
• Re: modules.dep and depmod.pl
  • From: "Dave Hylands" <dhylands@xxxxxxxxx>
• Re: Cross Compiler and loads of issues
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: Cross Compiler and loads of issues
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: modules.dep and depmod.pl
  • From: "Mike Frysinger" <vapier.adi@xxxxxxxxx>
• modules.dep and depmod.pl
  • From: "Linus Walleij" <linus.ml.walleij@xxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• about size optimizations (Re: Not as much ccache win as I expected)
  • From: "Oleg Verych" <olecom@xxxxxxxxx>
• Re: Not as much ccache win as I expected
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Not as much ccache win as I expected
  • From: "Oleg Verych" <olecom@xxxxxxxxx>