From: Rob Landley <rob@landley.net> To: chase rayfield <cusbrar1@gmail.com>, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Sam Ravnborg <sam@ravnborg.org>, Arnd Bergmann <arnd@arndb.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-m68k <linux-m68k@lists.linux-m68k.org>, Sparc kernel list <sparclinux@vger.kernel.org>, Linux-sh list <linux-sh@vger.kernel.org> Subject: Re: Old platforms: bring out your dead Date: Mon, 11 Jan 2021 18:26:38 -0600 [thread overview] Message-ID: <1f6e936c-4947-4952-fae2-c05d03e0cd2c@landley.net> (raw) In-Reply-To: <CACwypyNS+fVoPVspSr36v8YjFbkrnYb+amcYRqVmA2kD2uD1Wg@mail.gmail.com> On 1/11/21 8:55 AM, chase rayfield wrote: > On Mon, Jan 11, 2021 at 3:09 AM John Paul Adrian Glaubitz > <glaubitz@physik.fu-berlin.de> wrote: > >> >> I'm not sure I understand the reasoning for doing this. The SPARC architecture >> isn't going to see any new hardware developments in the future after Oracle >> let go of most of the SPARC developers. So it's not that we need to make room >> for new hardware. >> > My take is that there *would* be more interest in Sparc sun4m / Sun4d > from enthusiasts at the very least if it was possible to actually boot > the bloat hog that is Linux these days in a fully usable configuration > that probably means some modifications to SILO and Linux required. You can trim current linux down a bit, it's just non-obvious how. Unfortunately there's an "expert" menu and CONFIG_EMBEDDED and if you touch anything there's suddenly a hundred extra options in your config with no explanation of what they do. At least 50% of what you want is probably disabling the printk strings that aren't visible at your default verbosity level, but alas you must open pandora's box to access those options... > The problem is as I understand it, SILO only sets up a 16Mb mapping > (either due to having to assume 4MB minimum dram stick size or due to > mapping limitations not sure, most of these machines have at least > 16MB in slot one...these days though that wasn't the case for sun4c), > loads Linux into it and says good Luck. This isn't enough for a modern > kernel with any hardware support built in. So you might for instance > get a kernel to fit but only if you dropped all of networking support > etc... I'm guessing the fix for this would be to modify silo to map a > larger amount in a way that Linux expects so it can remap it as it > likes, or just have SILO map the full memory as Linux would. Anyway > that is THE main demotivation for these architectures.... otherwise > they have plenty of ram and performance to do basic router/server > tasks sans SSL. A lot of people with hardware like this haven't stopped using it, they've just stopped fighting with kernel upgrades. (Common issue in the embedded world. Not really a fun thing for security, but ) > This has been the status quo for since the last of the 2.6 series of > kernels which it was still possible to just barely squeeze a usable > kernel out of... If someone wanted to take a few hours and fix this > issue, and keep these architectures around I'd be happy to "buy them a > round of pizza", though I recognize that many people that work on this > already have nice jobs, and just don't have time. My https://github.com/landley/toybox/blob/master/scripts/mkroot.sh ~250 line bash script generates the simplest kernel configs for a bunch of platforms to boot qemu to a shell prompt, but you then have to open the "expert" menu and _disable_ stuff in order to get the size down from there. > Also Sparc would probably be a good project for someone to extend/test Sparc has a runtime relocation I've never understood but did manage to break once, resulting in a long thread to fix: http://lists.landley.net/pipermail/aboriginal-landley.net/2011-December/001964.html Between that and the weird save half the stack register thing with function calls on some sort of "wheel"... there's a _reason_ I haven't been able to talk Rich into adding support for it to musl. > Andi Keen's Linux LTO patch set so we could reduce the kernel binary > size that way also even if sun4 architectures are dropped, it would > still be useful for embedded sparc. Also there is a port of Temlib to > the Mister hardware now, 3 cores roughly equivalent to a mid 90s > machine, at least 128MB ram is possible ( more if a way to map the ARM > system memory also 1GB is available there, it would have higher > latency though). > > It is perfectly viable to build Sparc v7 or v8 32bit binaries in a > chroot on a fast machine also, and I would recommend this if you wish > to retain sanity rather than attempting cross compiler voodoo, unless > that is your thing. It is, sadly, my thing. The above 250 line bash script builds: aarch64 armv7l i686 mips powerpc s390x x86_64 armv4l armv7m m68k mips64 powerpc64 sh2eb armv5l i486 microblaze mipsel powerpc64le sh4 That's toybox booting to a shell prompt and a linux kernel configured for qemu for each target. Adding new targets looks something like: elif [ "$TARGET" == m68k ]; then QEMU="m68k -M q800" KARCH=m68k KARGS=ttyS0 VMLINUX=vmlinux KCONF=MMU,M68040,M68KFPU_EMU,MAC,SCSI_MAC_ESP,MACINTOSH_DRIVERS,ADB,ADB_MACII,NET_CORE,MACSONIC,SERIAL_PMACZILOG,SERIAL_PMACZILOG_TTYS,SERIAL_PMACZILOG_CONSOLE elif [ "$TARGET" = s390x ]; then QEMU="s390x" KARCH=s390 VMLINUX=arch/s390/boot/bzImage KCONF=MARCH_Z900,PACK_STACK,NET_CORE,VIRTIO_NET,VIRTIO_BLK,SCLP_TTY,SCLP_CONSOLE,SCLP_VT220_TTY,SCLP_VT220_CONSOLE,S390_GUEST (Well, modulo thunderbird being unable to an indent a line that goes off the right edge of the screen. The mozilla foundation somehow managed to spend half a billion dollars in 2019 but it wasn't on thunderbird, I can tell you that.) Anyway, I wrote a couple FAQ entries trying to explain the worst of it: https://landley.net/toybox/faq.html#cross https://landley.net/toybox/faq.html#mkroot > Anyways it could be that people that want this get around to fixing > SILO eventually and just sit on this last kernel version... *shrugs* They're never sitting on the _last_ kernel version. They're generally way back from there. Been true forever off of x86 (and now arm): https://lore.kernel.org/lkml/201002211025.11588.rob@landley.net/T/ > Chase Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Landley <rob@landley.net> To: chase rayfield <cusbrar1@gmail.com>, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Sam Ravnborg <sam@ravnborg.org>, Arnd Bergmann <arnd@arndb.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-m68k <linux-m68k@lists.linux-m68k.org>, Sparc kernel list <sparclinux@vger.kernel.org>, Linux-sh list <linux-sh@vger.kernel.org> Subject: Re: Old platforms: bring out your dead Date: Tue, 12 Jan 2021 00:26:38 +0000 [thread overview] Message-ID: <1f6e936c-4947-4952-fae2-c05d03e0cd2c@landley.net> (raw) In-Reply-To: <CACwypyNS+fVoPVspSr36v8YjFbkrnYb+amcYRqVmA2kD2uD1Wg@mail.gmail.com> On 1/11/21 8:55 AM, chase rayfield wrote: > On Mon, Jan 11, 2021 at 3:09 AM John Paul Adrian Glaubitz > <glaubitz@physik.fu-berlin.de> wrote: > >> >> I'm not sure I understand the reasoning for doing this. The SPARC architecture >> isn't going to see any new hardware developments in the future after Oracle >> let go of most of the SPARC developers. So it's not that we need to make room >> for new hardware. >> > My take is that there *would* be more interest in Sparc sun4m / Sun4d > from enthusiasts at the very least if it was possible to actually boot > the bloat hog that is Linux these days in a fully usable configuration > that probably means some modifications to SILO and Linux required. You can trim current linux down a bit, it's just non-obvious how. Unfortunately there's an "expert" menu and CONFIG_EMBEDDED and if you touch anything there's suddenly a hundred extra options in your config with no explanation of what they do. At least 50% of what you want is probably disabling the printk strings that aren't visible at your default verbosity level, but alas you must open pandora's box to access those options... > The problem is as I understand it, SILO only sets up a 16Mb mapping > (either due to having to assume 4MB minimum dram stick size or due to > mapping limitations not sure, most of these machines have at least > 16MB in slot one...these days though that wasn't the case for sun4c), > loads Linux into it and says good Luck. This isn't enough for a modern > kernel with any hardware support built in. So you might for instance > get a kernel to fit but only if you dropped all of networking support > etc... I'm guessing the fix for this would be to modify silo to map a > larger amount in a way that Linux expects so it can remap it as it > likes, or just have SILO map the full memory as Linux would. Anyway > that is THE main demotivation for these architectures.... otherwise > they have plenty of ram and performance to do basic router/server > tasks sans SSL. A lot of people with hardware like this haven't stopped using it, they've just stopped fighting with kernel upgrades. (Common issue in the embedded world. Not really a fun thing for security, but ) > This has been the status quo for since the last of the 2.6 series of > kernels which it was still possible to just barely squeeze a usable > kernel out of... If someone wanted to take a few hours and fix this > issue, and keep these architectures around I'd be happy to "buy them a > round of pizza", though I recognize that many people that work on this > already have nice jobs, and just don't have time. My https://github.com/landley/toybox/blob/master/scripts/mkroot.sh ~250 line bash script generates the simplest kernel configs for a bunch of platforms to boot qemu to a shell prompt, but you then have to open the "expert" menu and _disable_ stuff in order to get the size down from there. > Also Sparc would probably be a good project for someone to extend/test Sparc has a runtime relocation I've never understood but did manage to break once, resulting in a long thread to fix: http://lists.landley.net/pipermail/aboriginal-landley.net/2011-December/001964.html Between that and the weird save half the stack register thing with function calls on some sort of "wheel"... there's a _reason_ I haven't been able to talk Rich into adding support for it to musl. > Andi Keen's Linux LTO patch set so we could reduce the kernel binary > size that way also even if sun4 architectures are dropped, it would > still be useful for embedded sparc. Also there is a port of Temlib to > the Mister hardware now, 3 cores roughly equivalent to a mid 90s > machine, at least 128MB ram is possible ( more if a way to map the ARM > system memory also 1GB is available there, it would have higher > latency though). > > It is perfectly viable to build Sparc v7 or v8 32bit binaries in a > chroot on a fast machine also, and I would recommend this if you wish > to retain sanity rather than attempting cross compiler voodoo, unless > that is your thing. It is, sadly, my thing. The above 250 line bash script builds: aarch64 armv7l i686 mips powerpc s390x x86_64 armv4l armv7m m68k mips64 powerpc64 sh2eb armv5l i486 microblaze mipsel powerpc64le sh4 That's toybox booting to a shell prompt and a linux kernel configured for qemu for each target. Adding new targets looks something like: elif [ "$TARGET" = m68k ]; then QEMU="m68k -M q800" KARCH=m68k KARGS=ttyS0 VMLINUX=vmlinux KCONF=MMU,M68040,M68KFPU_EMU,MAC,SCSI_MAC_ESP,MACINTOSH_DRIVERS,ADB,ADB_MACII,NET_CORE,MACSONIC,SERIAL_PMACZILOG,SERIAL_PMACZILOG_TTYS,SERIAL_PMACZILOG_CONSOLE elif [ "$TARGET" = s390x ]; then QEMU="s390x" KARCH=s390 VMLINUX=arch/s390/boot/bzImage KCONF=MARCH_Z900,PACK_STACK,NET_CORE,VIRTIO_NET,VIRTIO_BLK,SCLP_TTY,SCLP_CONSOLE,SCLP_VT220_TTY,SCLP_VT220_CONSOLE,S390_GUEST (Well, modulo thunderbird being unable to an indent a line that goes off the right edge of the screen. The mozilla foundation somehow managed to spend half a billion dollars in 2019 but it wasn't on thunderbird, I can tell you that.) Anyway, I wrote a couple FAQ entries trying to explain the worst of it: https://landley.net/toybox/faq.html#cross https://landley.net/toybox/faq.html#mkroot > Anyways it could be that people that want this get around to fixing > SILO eventually and just sit on this last kernel version... *shrugs* They're never sitting on the _last_ kernel version. They're generally way back from there. Been true forever off of x86 (and now arm): https://lore.kernel.org/lkml/201002211025.11588.rob@landley.net/T/ > Chase Rob
next prev parent reply other threads:[~2021-01-12 0:26 UTC|newest] Thread overview: 246+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-08 22:55 Old platforms: bring out your dead Arnd Bergmann 2021-01-08 22:55 ` Arnd Bergmann 2021-01-08 23:32 ` Steven Rostedt 2021-01-08 23:32 ` Steven Rostedt 2021-01-09 22:04 ` Arnd Bergmann 2021-01-09 22:04 ` Arnd Bergmann 2021-01-08 23:44 ` Thomas Bogendoerfer 2021-01-08 23:44 ` Thomas Bogendoerfer 2021-01-09 0:16 ` Linus Walleij 2021-01-09 0:16 ` Linus Walleij 2021-01-09 17:32 ` Florian Fainelli 2021-01-09 17:32 ` Florian Fainelli 2021-01-09 21:59 ` Arnd Bergmann 2021-01-09 21:59 ` Arnd Bergmann 2021-01-09 5:56 ` Willy Tarreau 2021-01-09 5:56 ` Willy Tarreau 2021-01-09 21:52 ` Arnd Bergmann 2021-01-09 21:52 ` Arnd Bergmann 2021-01-10 6:21 ` Willy Tarreau 2021-01-10 6:21 ` Willy Tarreau 2021-01-10 10:44 ` Russell King - ARM Linux admin 2021-01-10 10:44 ` Russell King - ARM Linux admin 2021-01-11 9:50 ` David Laight 2021-01-11 9:50 ` David Laight 2021-01-13 10:27 ` Andy Shevchenko 2021-01-13 10:27 ` Andy Shevchenko 2021-01-13 12:02 ` Linus Walleij 2021-01-13 12:02 ` Linus Walleij 2021-01-13 12:17 ` Andy Shevchenko 2021-01-13 12:17 ` Andy Shevchenko 2021-01-13 12:21 ` Andy Shevchenko 2021-01-13 12:21 ` Andy Shevchenko 2021-01-15 0:03 ` Bernd Petrovitsch 2021-01-15 0:03 ` Bernd Petrovitsch 2021-01-15 0:24 ` William Breathitt Gray 2021-01-15 0:24 ` William Breathitt Gray 2021-01-15 8:59 ` David Laight 2021-01-15 8:59 ` David Laight 2021-01-13 12:30 ` William Breathitt Gray 2021-01-13 12:30 ` William Breathitt Gray 2021-01-13 12:56 ` William Breathitt Gray 2021-01-13 12:56 ` William Breathitt Gray 2021-01-13 13:44 ` Arnd Bergmann 2021-01-13 13:44 ` Arnd Bergmann 2021-02-04 21:01 ` Pavel Machek 2021-02-04 21:01 ` Pavel Machek 2021-02-05 9:13 ` David Laight 2021-02-05 9:13 ` David Laight 2021-02-05 9:29 ` Pavel Machek 2021-02-05 9:29 ` Pavel Machek 2021-01-09 17:34 ` Florian Fainelli 2021-01-09 17:34 ` Florian Fainelli 2021-01-09 21:18 ` Arnd Bergmann 2021-01-09 21:18 ` Arnd Bergmann 2021-01-09 17:43 ` Russell King - ARM Linux admin 2021-01-09 17:43 ` Russell King - ARM Linux admin 2021-01-09 21:34 ` Arnd Bergmann 2021-01-09 21:34 ` Arnd Bergmann 2021-01-11 20:09 ` Russell King - ARM Linux admin 2021-01-11 20:09 ` Russell King - ARM Linux admin 2021-01-09 20:19 ` Baruch Siach 2021-01-09 20:19 ` Baruch Siach 2021-01-09 21:19 ` Arnd Bergmann 2021-01-09 21:19 ` Arnd Bergmann [not found] ` <67171E13-6786-4B44-A8C2-3302963B055F@gmail.com> 2021-01-09 22:20 ` Arnd Bergmann 2021-01-09 22:20 ` Arnd Bergmann 2021-01-10 18:12 ` Fabian Vogt 2021-01-10 18:12 ` Fabian Vogt 2021-01-10 19:20 ` Arnd Bergmann 2021-01-10 19:20 ` Arnd Bergmann 2021-01-10 21:33 ` Linus Walleij 2021-01-10 21:33 ` Linus Walleij 2021-01-11 0:33 ` Russell King - ARM Linux admin 2021-01-11 0:33 ` Russell King - ARM Linux admin 2021-01-11 12:32 ` Arnd Bergmann 2021-01-11 12:32 ` Arnd Bergmann 2021-01-11 12:36 ` Russell King - ARM Linux admin 2021-01-11 12:36 ` Russell King - ARM Linux admin 2021-01-09 23:12 ` Andrew Lunn 2021-01-09 23:12 ` Andrew Lunn 2021-01-10 8:45 ` Arnd Bergmann 2021-01-10 8:45 ` Arnd Bergmann 2021-01-10 16:46 ` Andrew Lunn 2021-01-10 16:46 ` Andrew Lunn 2021-01-10 17:27 ` Arnd Bergmann 2021-01-10 17:27 ` Arnd Bergmann 2021-01-10 19:51 ` Andrew Lunn 2021-01-10 19:51 ` Andrew Lunn 2021-01-10 15:51 ` Neil Armstrong 2021-01-10 15:51 ` Neil Armstrong 2021-01-10 15:56 ` Arnd Bergmann 2021-01-10 15:56 ` Arnd Bergmann 2021-01-10 17:35 ` John Paul Adrian Glaubitz 2021-01-10 17:35 ` John Paul Adrian Glaubitz 2021-01-10 21:46 ` Sam Ravnborg 2021-01-10 21:46 ` Sam Ravnborg 2021-01-11 8:05 ` John Paul Adrian Glaubitz 2021-01-11 8:05 ` John Paul Adrian Glaubitz 2021-01-11 14:55 ` chase rayfield 2021-01-11 14:55 ` chase rayfield 2021-01-12 0:26 ` Rob Landley [this message] 2021-01-12 0:26 ` Rob Landley 2021-01-12 0:50 ` chase rayfield 2021-01-12 0:50 ` chase rayfield 2021-01-12 14:37 ` John Paul Adrian Glaubitz 2021-01-12 14:37 ` John Paul Adrian Glaubitz 2021-01-11 17:57 ` Rob Landley 2021-01-11 18:09 ` Rob Landley 2021-01-11 15:04 ` Gerhard Pircher 2021-01-11 15:04 ` Gerhard Pircher 2021-01-12 14:44 ` John Paul Adrian Glaubitz 2021-01-12 14:44 ` John Paul Adrian Glaubitz 2021-01-12 22:46 ` Linus Walleij 2021-01-12 22:46 ` Linus Walleij 2021-01-13 7:57 ` Rob Landley 2021-01-13 8:09 ` Rob Landley 2021-01-13 8:21 ` Geert Uytterhoeven 2021-01-13 8:21 ` Geert Uytterhoeven 2021-01-13 13:25 ` Rob Landley 2021-01-13 13:25 ` Rob Landley 2021-01-13 12:02 ` Andy Shevchenko 2021-01-13 12:02 ` Andy Shevchenko 2021-01-13 8:15 ` Geert Uytterhoeven 2021-01-13 8:15 ` Geert Uytterhoeven 2021-01-13 10:39 ` Arnd Bergmann 2021-01-13 10:39 ` Arnd Bergmann 2021-01-14 3:54 ` New platforms: bring out your dead, was " Finn Thain 2021-01-14 3:54 ` Finn Thain 2021-01-14 9:41 ` John Paul Adrian Glaubitz 2021-01-14 9:41 ` John Paul Adrian Glaubitz 2021-01-14 9:48 ` Geert Uytterhoeven 2021-01-14 9:48 ` Geert Uytterhoeven 2021-01-14 21:21 ` Arnd Bergmann 2021-01-14 21:21 ` Arnd Bergmann 2021-01-14 22:54 ` Undesirable code, was Re: Old platforms etc Finn Thain 2021-01-14 22:54 ` Finn Thain 2021-01-14 23:09 ` Old platforms: bring out your dead Max Filippov 2021-01-14 23:09 ` Max Filippov 2021-01-15 8:31 ` Arnd Bergmann 2021-01-15 8:31 ` Arnd Bergmann 2021-01-13 0:12 ` Old platforms never die, was " Finn Thain 2021-01-13 0:12 ` Finn Thain 2021-01-16 6:54 ` Rob Landley 2021-01-16 6:54 ` Rob Landley 2021-01-16 23:22 ` Finn Thain 2021-01-16 23:22 ` Finn Thain 2021-01-13 11:47 ` Andy Shevchenko 2021-01-13 11:47 ` Andy Shevchenko 2021-01-11 1:39 ` Daniel Palmer 2021-01-11 1:39 ` Daniel Palmer 2021-01-11 9:15 ` John Paul Adrian Glaubitz 2021-01-11 9:15 ` John Paul Adrian Glaubitz 2021-01-11 9:20 ` Geert Uytterhoeven 2021-01-11 9:20 ` Geert Uytterhoeven 2021-01-11 9:26 ` John Paul Adrian Glaubitz 2021-01-11 9:26 ` John Paul Adrian Glaubitz 2021-01-11 9:36 ` Geert Uytterhoeven 2021-01-11 9:36 ` Geert Uytterhoeven 2021-01-11 9:50 ` Greg Ungerer 2021-01-11 9:50 ` Greg Ungerer 2021-01-11 9:42 ` Daniel Palmer 2021-01-11 9:42 ` Daniel Palmer 2021-01-11 10:13 ` Arnd Bergmann 2021-01-11 10:13 ` Arnd Bergmann 2021-01-11 8:19 ` Geert Uytterhoeven 2021-01-11 8:19 ` Geert Uytterhoeven 2021-01-11 8:59 ` Arnd Bergmann 2021-01-11 8:59 ` Arnd Bergmann 2021-01-11 9:16 ` Geert Uytterhoeven 2021-01-11 9:16 ` Geert Uytterhoeven 2021-01-11 10:28 ` Geert Uytterhoeven 2021-01-11 10:28 ` Geert Uytterhoeven 2021-01-11 10:37 ` Arnd Bergmann 2021-01-11 10:37 ` Arnd Bergmann 2021-01-11 9:40 ` Thomas Bogendoerfer 2021-01-11 9:40 ` Thomas Bogendoerfer 2021-01-11 10:34 ` Arnd Bergmann 2021-01-11 10:34 ` Arnd Bergmann 2021-01-11 8:40 ` efm32 is dead [Was: Old platforms: bring out your dead] Uwe Kleine-König 2021-01-11 8:49 ` Old platforms: bring out your dead Alexander Sverdlin 2021-01-11 9:31 ` Arnd Bergmann 2021-01-11 10:27 ` Alexander Sverdlin 2021-01-11 11:00 ` Arnd Bergmann 2021-01-11 8:53 ` Alexander Sverdlin 2021-01-11 11:10 ` Viresh Kumar 2021-01-11 11:10 ` Viresh Kumar 2021-01-11 19:59 ` Arnd Bergmann 2021-01-11 19:59 ` Arnd Bergmann 2021-01-11 21:15 ` Mattias Wallin 2021-01-11 21:15 ` Mattias Wallin 2021-01-11 21:47 ` Arnd Bergmann 2021-01-11 21:47 ` Arnd Bergmann 2021-01-11 13:13 ` Marc Gonzalez 2021-01-11 13:13 ` Marc Gonzalez 2021-01-11 17:29 ` Måns Rullgård 2021-01-11 17:29 ` Måns Rullgård 2021-01-11 21:50 ` Arnd Bergmann 2021-01-11 21:50 ` Arnd Bergmann 2021-01-12 8:23 ` Marc Gonzalez 2021-01-12 8:23 ` Marc Gonzalez 2021-01-11 14:22 ` Mark Salter 2021-01-11 14:22 ` Mark Salter 2021-01-11 15:00 ` Arnd Bergmann 2021-01-11 15:00 ` Arnd Bergmann 2021-01-11 14:44 ` Alexander Shiyan 2021-01-11 14:44 ` Alexander Shiyan 2021-01-11 14:58 ` Arnd Bergmann 2021-01-11 14:58 ` Arnd Bergmann 2021-01-11 16:23 ` Sylvain Lemieux 2021-01-11 16:23 ` Sylvain Lemieux 2021-01-11 22:17 ` Alexandre Belloni 2021-01-11 22:17 ` Alexandre Belloni 2021-01-11 19:58 ` Thomas Petazzoni 2021-01-11 19:58 ` Thomas Petazzoni 2021-01-11 20:10 ` Arnd Bergmann 2021-01-11 20:10 ` Arnd Bergmann 2021-01-11 20:25 ` Song Bao Hua (Barry Song) 2021-01-11 20:25 ` Song Bao Hua (Barry Song) 2021-01-12 8:41 ` Marc Gonzalez 2021-01-12 8:41 ` Marc Gonzalez 2021-01-13 10:30 ` Andy Shevchenko 2021-01-13 10:30 ` Andy Shevchenko 2021-01-13 11:02 ` Arnd Bergmann 2021-01-13 11:02 ` Arnd Bergmann 2021-01-13 16:14 ` [v2] " Arnd Bergmann 2021-01-13 19:00 ` Krzysztof Hałasa 2021-01-13 19:00 ` Krzysztof Hałasa 2021-01-14 8:51 ` Arnd Bergmann 2021-01-14 8:51 ` Arnd Bergmann 2021-01-15 7:08 ` Wei Xu 2021-01-15 7:08 ` Wei Xu 2021-01-15 9:26 ` Arnd Bergmann 2021-01-15 9:26 ` Arnd Bergmann 2021-01-15 11:09 ` Leizhen (ThunderTown) 2021-01-15 11:09 ` Leizhen (ThunderTown) 2021-01-15 12:04 ` Arnd Bergmann 2021-01-15 12:04 ` Arnd Bergmann 2021-01-18 10:46 ` Wei Xu 2021-01-18 10:46 ` Wei Xu 2021-01-13 22:27 ` Richard Z 2021-01-13 22:27 ` Richard Z 2021-02-05 13:37 ` Alexander Lobakin 2021-02-05 13:37 ` Alexander Lobakin 2021-10-23 17:44 ` Maciej W. Rozycki 2021-10-23 17:44 ` Maciej W. Rozycki 2021-01-12 2:05 tedheadster
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1f6e936c-4947-4952-fae2-c05d03e0cd2c@landley.net \ --to=rob@landley.net \ --cc=arnd@arndb.de \ --cc=cusbrar1@gmail.com \ --cc=glaubitz@physik.fu-berlin.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-m68k@lists.linux-m68k.org \ --cc=linux-sh@vger.kernel.org \ --cc=sam@ravnborg.org \ --cc=sparclinux@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.