linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Hajime Tazaki <thehajime@gmail.com>
Cc: linux-um@lists.infradead.org, ricarkol@google.com,
	Liam.Howlett@oracle.com,  vbabka@suse.cz, linux-mm@kvack.org,
	Jann Horn <jannh@google.com>, Christoph Hellwig <hch@lst.de>,
	Damien Le Moal <Damien.LeMoal@wdc.com>
Subject: Re: [RFC PATCH v2 00/13] nommu UML
Date: Fri, 22 Nov 2024 10:53:18 +0100	[thread overview]
Message-ID: <0930a0fa8e28ecaf92727229e6633278399409e7.camel@sipsolutions.net> (raw)
In-Reply-To: <77ab71c7-3608-4636-a618-3044c2316a92@lucifer.local>

On Fri, 2024-11-22 at 09:33 +0000, Lorenzo Stoakes wrote:
> 
> In general, while I appreciate your work and don't mean to be negative, we
> in mm consistently have problems with nommu as it is a rarely-tested
> more-or-less hack used for very few very old architectures and a constant
> source of problems and maintenance overhead for us.
> 
> It also complicates mm code and time taken to develop new features.
> 
> So ideally we'd avoid doing anything that requires us maintain it going
> forward unless the benefits really overwhelmingly outweigh the drawbacks.

:)

There aren't really any benefits to ARCH=um in *itself*, IMHO.

> There have been various murmourings about moving towards elimination of
> nommu, obviously this would entirely prevent that.

No objection from me, but e.g. RISC-V added nommu somewhat recently?
(+Christoph, Damien)

So we could argue the other way around and say that while we have other
architectures with nommu (like RISC-V), having ARCH=um could simplify
testing by e.g. allowing a kunit configuration in ARCH=um which is
simpler (and probably faster) to run for most people than simulating a
foreign architecture.

Anyway, I think that's where I am with my partial (and very limited)
ARCH=um maintainer role. I don't really care for having the feature in
UML itself, but if it's useful for testing nommu architectures for
someone else, it doesn't seem too problematic to support. And testing
such things is also a big part of the argument Hajime was making,
afaict.

johannes


  reply	other threads:[~2024-11-22  9:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1729770373.git.thehajime@gmail.com>
2024-10-24 12:09 ` [RFC PATCH 01/13] fs: binfmt_elf_efpic: add architecture hook elf_arch_finalize_exec Hajime Tazaki
2024-10-24 12:09 ` [RFC PATCH 02/13] x86/um: nommu: elf loader for fdpic Hajime Tazaki
2024-10-25  8:56   ` Johannes Berg
2024-10-25 12:54     ` Hajime Tazaki
     [not found] ` <cover.1731290567.git.thehajime@gmail.com>
2024-11-11  6:27   ` [RFC PATCH v2 01/13] fs: binfmt_elf_efpic: add architecture hook elf_arch_finalize_exec Hajime Tazaki
2024-11-11  6:27   ` [RFC PATCH v2 02/13] x86/um: nommu: elf loader for fdpic Hajime Tazaki
2024-11-12 12:48     ` Geert Uytterhoeven
2024-11-12 22:07       ` Hajime Tazaki
2024-11-13  8:19         ` Geert Uytterhoeven
2024-11-13  8:36           ` Johannes Berg
2024-11-13  8:36             ` Johannes Berg
2024-11-13 10:27               ` Geert Uytterhoeven
2024-11-13 13:17                 ` Hajime Tazaki
2024-11-13 13:55                   ` Geert Uytterhoeven
2024-11-13 23:32                     ` Hajime Tazaki
2024-11-14  1:40                       ` Greg Ungerer
2024-11-14 10:41                         ` Hajime Tazaki
2024-11-22  9:33   ` [RFC PATCH v2 00/13] nommu UML Lorenzo Stoakes
2024-11-22  9:53     ` Johannes Berg [this message]
2024-11-22 10:29       ` Lorenzo Stoakes
2024-11-22 12:18       ` Christoph Hellwig
2024-11-22 12:25         ` Lorenzo Stoakes
2024-11-22 12:38           ` Christoph Hellwig
2024-11-22 12:49             ` Damien Le Moal
2024-11-22 12:52               ` Lorenzo Stoakes

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=0930a0fa8e28ecaf92727229e6633278399409e7.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=Damien.LeMoal@wdc.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=hch@lst.de \
    --cc=jannh@google.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-um@lists.infradead.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=ricarkol@google.com \
    --cc=thehajime@gmail.com \
    --cc=vbabka@suse.cz \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox