Re: [PATCH 00/16] remove eight obsolete architectures
On Thu, 15 Mar 2018 03:42:25 PDT (-0700), Arnd Bergmann wrote: On Thu, Mar 15, 2018 at 10:59 AM, Hannes Reinecke wrote: On 03/15/2018 10:42 AM, David Howells wrote: Do we have anything left that still implements NOMMU? RISC-V ? (evil grin :-) Is anyone producing a chip that includes enough of the Privileged ISA spec to have things like system calls, but not the MMU parts? I thought at least initially the kernel only supports hardware that has a rather complete feature set. We currently do not have a NOMMU port. As far as I know, everyone who's currently producing RISC-V hardware with enough memory to run Linux has S mode with paging support. The ISA allows for S mode without paging but there's no hardware for that -- if you're going to put a DRAM controller on there then paging seems pretty cheap. You could run a NOMMU port on a system with S-mode and paging, but With all the superpage stuff I don't think you'll get an appreciable performance win for any workload running without an MMU so there's nothing to justify the work (and incompatibility) of a NOMMU port there. While I think you could implement a NOMMU port on a machine with only M and U modes (and therefor no address translation at all), I don't know of any MU-only machines that have enough memory to run Linux (ours have less than 32KiB). A SBI-free Linux would be a prerequisite for this, but there's some interest in that outside of a NOMMU port so it might materialize anyway. Of course, QEMU could probably be tricked into emulating one of these machines with little to no effort :)... That said, I doubt we'll see a NOMMU port materialize without some real hardware as it's a lot of work for a QEMU-only target.
Re: [PATCH 00/16] remove eight obsolete architectures
Hi, On Thu, Mar 15, 2018 at 10:56:48AM +0100, Arnd Bergmann wrote: > On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote: > > Do we have anything left that still implements NOMMU? Please don't kill !MMU. > Yes, plenty. > I've made an overview of the remaining architectures for my own reference[1]. > The remaining NOMMU architectures are: > > - arch/arm has ARMv7-M (Cortex-M microcontroller), which is actually > gaining traction ARMv7-R as well, also seems ARM is coming up with more !MMU's - v8-M, v8-R. In addition, though only of academic interest, ARM MMU capable platform's can run !MMU Linux. afzal > - arch/sh has an open-source J2 core that was added not that long ago, > it seems to > be the only SH compatible core that anyone is working on. > - arch/microblaze supports both MMU/NOMMU modes (most use an MMU) > - arch/m68k supports several NOMMU targets, both the coldfire SoCs and the > classic processors > - c6x has no MMU
Re: rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)
On Thu, 2018-03-15 at 10:08 -0700, Matthew Wilcox wrote: > On Thu, Mar 15, 2018 at 09:56:46AM -0700, Joe Perches wrote: > > I have a patchset that creates a vsprintf extension for > > print_vma_addr and removes all the uses similar to the > > print_symbol() removal. > > > > This now avoids any possible printk interleaving. > > > > Unfortunately, without some #ifdef in vsprintf, which > > I would like to avoid, it increases the nommu kernel > > size by ~500 bytes. > > > > Anyone think this is acceptable? [] > This doesn't feel like a huge win since it's only called ~once per > architecture. I'd be more excited if it made the printing of the whole > thing standardised; eg we have a print_fault() function in mm/memory.c > which takes a suitable set of arguments. Sure but perhaps that's not feasible as the surrounding output is per-arch specific. What could be a standardized fault message here?
Re: rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)
On Thu, Mar 15, 2018 at 09:56:46AM -0700, Joe Perches wrote: > I have a patchset that creates a vsprintf extension for > print_vma_addr and removes all the uses similar to the > print_symbol() removal. > > This now avoids any possible printk interleaving. > > Unfortunately, without some #ifdef in vsprintf, which > I would like to avoid, it increases the nommu kernel > size by ~500 bytes. > > Anyone think this is acceptable? > > Here's the overall patch, but I have it as a series > --- > Documentation/core-api/printk-formats.rst | 9 + > arch/arm64/kernel/traps.c | 13 +++ > arch/mips/mm/fault.c | 16 - > arch/parisc/mm/fault.c| 15 > arch/riscv/kernel/traps.c | 11 +++--- > arch/s390/mm/fault.c | 7 ++-- > arch/sparc/mm/fault_32.c | 8 ++--- > arch/sparc/mm/fault_64.c | 8 ++--- > arch/tile/kernel/signal.c | 9 ++--- > arch/um/kernel/trap.c | 13 +++ > arch/x86/kernel/signal.c | 10 ++ > arch/x86/kernel/traps.c | 18 -- > arch/x86/mm/fault.c | 12 +++ > include/linux/mm.h| 1 - > lib/vsprintf.c| 58 > ++- > mm/memory.c | 33 -- > 16 files changed, 112 insertions(+), 129 deletions(-) This doesn't feel like a huge win since it's only called ~once per architecture. I'd be more excited if it made the printing of the whole thing standardised; eg we have a print_fault() function in mm/memory.c which takes a suitable set of arguments.
rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)
On Thu, 2018-03-15 at 10:48 +0100, Geert Uytterhoeven wrote:
> Hi David,
>
> On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote:
> > Do we have anything left that still implements NOMMU?
>
> Sure: arm, c6x, m68k, microblaze, and sh.
I have a patchset that creates a vsprintf extension for
print_vma_addr and removes all the uses similar to the
print_symbol() removal.
This now avoids any possible printk interleaving.
Unfortunately, without some #ifdef in vsprintf, which
I would like to avoid, it increases the nommu kernel
size by ~500 bytes.
Anyone think this is acceptable?
Here's the overall patch, but I have it as a series
---
Documentation/core-api/printk-formats.rst | 9 +
arch/arm64/kernel/traps.c | 13 +++
arch/mips/mm/fault.c | 16 -
arch/parisc/mm/fault.c| 15
arch/riscv/kernel/traps.c | 11 +++---
arch/s390/mm/fault.c | 7 ++--
arch/sparc/mm/fault_32.c | 8 ++---
arch/sparc/mm/fault_64.c | 8 ++---
arch/tile/kernel/signal.c | 9 ++---
arch/um/kernel/trap.c | 13 +++
arch/x86/kernel/signal.c | 10 ++
arch/x86/kernel/traps.c | 18 --
arch/x86/mm/fault.c | 12 +++
include/linux/mm.h| 1 -
lib/vsprintf.c| 58 ++-
mm/memory.c | 33 --
16 files changed, 112 insertions(+), 129 deletions(-)
diff --git a/Documentation/core-api/printk-formats.rst
b/Documentation/core-api/printk-formats.rst
index 934559b3c130..10a91da1bc83 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -157,6 +157,15 @@ DMA address types dma_addr_t
For printing a dma_addr_t type which can vary based on build options,
regardless of the width of the CPU data path.
+VMA name and address
+
+
+::
+
+ %pav[hexstart+hexsize] or ?[0+0] if unavailable
+
+For any address, print the vma's name and its starting address and size
+
Passed by reference.
Raw buffer as an escaped string
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 2b478565d774..48edf812ce8b 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -242,13 +242,14 @@ void arm64_force_sig_info(struct siginfo *info, const
char *str,
if (!show_unhandled_signals_ratelimited())
goto send_sig;
- pr_info("%s[%d]: unhandled exception: ", tsk->comm, task_pid_nr(tsk));
if (esr)
- pr_cont("%s, ESR 0x%08x, ", esr_get_class_string(esr), esr);
-
- pr_cont("%s", str);
- print_vma_addr(KERN_CONT " in ", regs->pc);
- pr_cont("\n");
+ pr_info("%s[%d]: unhandled exception: %s, ESR 0x%08x, %s in
%pav\n",
+ tsk->comm, task_pid_nr(tsk),
+ esr_get_class_string(esr), esr,
+ str, ®s->pc);
+ else
+ pr_info("%s[%d]: unhandled exception: %s in %pav\n",
+ tsk->comm, task_pid_nr(tsk), str, ®s->pc);
__show_regs(regs);
send_sig:
diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index 4f8f5bf46977..ce7bf077a0f5 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c
@@ -213,14 +213,14 @@ static void __kprobes __do_page_fault(struct pt_regs
*regs, unsigned long write,
tsk->comm,
write ? "write access to" : "read access from",
field, address);
- pr_info("epc = %0*lx in", field,
- (unsigned long) regs->cp0_epc);
- print_vma_addr(KERN_CONT " ", regs->cp0_epc);
- pr_cont("\n");
- pr_info("ra = %0*lx in", field,
- (unsigned long) regs->regs[31]);
- print_vma_addr(KERN_CONT " ", regs->regs[31]);
- pr_cont("\n");
+ pr_info("epc = %0*lx in %pav\n",
+ field,
+ (unsigned long)regs->cp0_epc,
+ ®s->cp0_epc);
+ pr_info("ra = %0*lx in %pav\n",
+ field,
+ (unsigned long)regs->regs[31],
+ ®s->regs[31]);
}
current->thread.trap_nr = (regs->cp0_cause >> 2) & 0x1f;
info.si_signo = SIGSEGV;
diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
index e247edbca68e..877cea702714 100644
--- a/arch/parisc/mm/fault.c
+++ b/arch/parisc/mm/fault.c
@@ -240,17 +240,14 @@ show_signal_msg(struct pt_regs *regs, unsigned long code,
Re: [PATCH 00/16] remove eight obsolete architectures
On Thu, Mar 15, 2018 at 11:42:25AM +0100, Arnd Bergmann wrote: > Is anyone producing a chip that includes enough of the Privileged ISA spec > to have things like system calls, but not the MMU parts? Various SiFive SOCs seem to support M and U mode, but no S mode or iommu. That should be enough for nommu Linux running in M mode if someone cares enough to actually port it.
Re: [PATCH 00/16] remove eight obsolete architectures
On Thu, Mar 15, 2018 at 10:59 AM, Hannes Reinecke wrote: > On 03/15/2018 10:42 AM, David Howells wrote: >> Do we have anything left that still implements NOMMU? >> > RISC-V ? > (evil grin :-) Is anyone producing a chip that includes enough of the Privileged ISA spec to have things like system calls, but not the MMU parts? I thought at least initially the kernel only supports hardware that has a rather complete feature set. Arnd
Re: [PATCH 00/16] remove eight obsolete architectures
On 03/15/2018 10:42 AM, David Howells wrote: > Do we have anything left that still implements NOMMU? > RISC-V ? (evil grin :-) Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Re: [PATCH 00/16] remove eight obsolete architectures
On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote: > Do we have anything left that still implements NOMMU? Yes, plenty. I was wondering the same thing, but it seems that the architectures we remove are almost completely representative of what we support overall, except that they are all not licensed to 3rd parties, unlike many of the ones we keep. I've made an overview of the remaining architectures for my own reference[1]. The remaining NOMMU architectures are: - arch/arm has ARMv7-M (Cortex-M microcontroller), which is actually gaining traction - arch/sh has an open-source J2 core that was added not that long ago, it seems to be the only SH compatible core that anyone is working on. - arch/microblaze supports both MMU/NOMMU modes (most use an MMU) - arch/m68k supports several NOMMU targets, both the coldfire SoCs and the classic processors - c6x has no MMU Arnd [1] https://docs.google.com/spreadsheets/d/1QxMvW5jpVG2jb4RM9CQQl27-wVpNYOa-_3K2RVKifb0
Re: [PATCH 00/16] remove eight obsolete architectures
Hi David,
On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote:
> Do we have anything left that still implements NOMMU?
Sure: arm, c6x, m68k, microblaze, and sh.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 00/16] remove eight obsolete architectures
Do we have anything left that still implements NOMMU? David
[PATCH 00/16] remove eight obsolete architectures
Here is the collection of patches I have applied to my 'asm-generic' tree on top of the 'metag' removal. This does not include any of the device drivers, I'll send those separately to a someone different list of people. The removal came out of a discussion that is now documented at https://lwn.net/Articles/748074/ Following up from the state described there, I ended up removing the mn10300, tile, blackfin and cris architectures directly, rather than waiting, after consulting with the respective maintainers. However, the unicore32 architecture is no longer part of the removal, after its maintainer Xuetao Guan said that the port is still actively being used and that he intends to keep working on it, and that he will try to provide updated toolchain sources. In the end, it seems that while the eight architectures are extremely different, they all suffered the same fate: There was one company in charge of an SoC line, a CPU microarchitecture and a software ecosystem, which was more costly than licensing newer off-the-shelf CPU cores from a third party (typically ARM, MIPS, or RISC-V). It seems that all the SoC product lines are still around, but have not used the custom CPU architectures for several years at this point. Arnd Arnd Bergmann (14): arch: remove frv port arch: remove m32r port arch: remove score port arch: remove blackfin port arch: remove tile port procfs: remove CONFIG_HARDWALL dependency mm: remove blackfin MPU support mm: remove obsolete alloc_remap() treewide: simplify Kconfig dependencies for removed archs asm-generic: siginfo: remove obsolete #ifdefs Documentation: arch-support: remove obsolete architectures asm-generic: clean up asm/unistd.h recordmcount.pl: drop blackin and tile support ktest: remove obsolete architectures David Howells (1): mn10300: Remove the architecture Jesper Nilsson (1): CRIS: Drop support for the CRIS port Dirstat only (full diffstat is over 100KB): 6.3% arch/blackfin/mach-bf548/include/mach/ 4.5% arch/blackfin/mach-bf609/include/mach/ 26.3% arch/blackfin/ 4.1% arch/cris/arch-v32/ 5.6% arch/cris/include/arch-v32/arch/hwregs/iop/ 4.1% arch/cris/include/arch-v32/mach-a3/mach/hwregs/ 4.7% arch/cris/include/arch-v32/ 7.8% arch/cris/ 5.6% arch/frv/ 5.5% arch/m32r/ 7.0% arch/mn10300/ 7.6% arch/tile/include/ 6.4% arch/tile/kernel/ 0.0% Documentation/admin-guide/ 0.0% Documentation/blackfin/ 0.0% Documentation/cris/ 0.0% Documentation/devicetree/bindings/cris/ 0.0% Documentation/devicetree/bindings/interrupt-controller/ 2.8% Documentation/features/ 0.5% Documentation/frv/ 0.0% Documentation/ioctl/ 0.0% Documentation/mn10300/ 0.0% Documentation/ 0.0% block/ 0.0% crypto/ 0.0% drivers/ide/ 0.0% drivers/input/joystick/ 0.0% drivers/isdn/hisax/ 0.0% drivers/net/ethernet/davicom/ 0.0% drivers/net/ethernet/smsc/ 0.0% drivers/net/wireless/cisco/ 0.0% drivers/pci/ 0.0% drivers/pwm/ 0.0% drivers/rtc/ 0.0% drivers/spi/ 0.0% drivers/staging/speakup/ 0.0% drivers/usb/musb/ 0.0% drivers/video/console/ 0.0% drivers/watchdog/ 0.0% fs/minix/ 0.0% fs/proc/ 0.0% fs/ 0.0% include/asm-generic/ 0.0% include/linux/ 0.0% include/uapi/asm-generic/ 0.0% init/ 0.0% kernel/ 0.0% lib/ 0.0% mm/ 0.0% samples/blackfin/ 0.0% samples/kprobes/ 0.0% samples/ 0.0% scripts/mod/ 0.0% scripts/ 0.0% tools/arch/frv/include/uapi/asm/ 0.0% tools/arch/m32r/include/uapi/asm/ 0.0% tools/arch/mn10300/include/uapi/asm/ 0.0% tools/arch/score/include/uapi/asm/ 0.0% tools/arch/tile/include/asm/ 0.0% tools/arch/tile/include/uapi/asm/ 0.0% tools/include/asm-generic/ 0.0% tools/scripts/ 0.0% tools/testing/ktest/examples/ 0.0% tools/testing/ktest/ Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-bl...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-wirel...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Cc: linux-watch...@vger.kernel.org Cc: linux-fsde...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux...@kvack.org
