Re: [PATCH] riscv: deprecate CONFIG_MMU=n

From: Jisheng Zhang
Date: Thu Mar 14 2024 - 08:59:34 EST


On Tue, Feb 27, 2024 at 08:38:50AM -0800, Palmer Dabbelt wrote:
> On Tue, 27 Feb 2024 01:11:41 PST (-0800), cleger@xxxxxxxxxxxx wrote:
> >
> >
> > On 26/02/2024 20:00, Charles Lohr wrote:
> > > WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
> > > and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
> > > for Linux, as well as some limited systems.
>
> OK.
>
> I just build test this stuff, as I don't really have a use for it
> personally. I figured if nobody's reporting bugs then probably it's broken
> and nobody's noticed because nobody's using it.
>
> > > I get new copies of the kernel when there are releases and test them
> > > frequently to make sure everything is still working as expected.
>
> I'd actually expected it to be broken, but I guess we managed to avoid
> screwing things up ;)
>
> > > For us we just don't care about XIP. I mean if someone did push it

I don't care XIP either, and IMHO the XIP's maintenance effort is much
bigger than NOMMU(just check the various XIP_FIXUP* or CONFIG_XIP_KERNEL
macros around lowlevel pgtable.h, page.h). If we can remove XIP, the
code readability will be much better.

Or sending out a similar XIP deprecation patch to see whether there's
any complain ? ;)

> > > through to fruition, I'd also test and use it, but I urge you please
> > > do not deprecate this. While it's sometimes needed a bit of a

+1 for urge the upstream please do not deprecate NOMMU.

Besides the soft(FPGA) core mentioned by Charles, here is another real
usage case: As is known, Sophgo CV1800B platforms such as Milk Duo
contains two C906 core, one(a.k.a big core) with MMU another(a.k.a small
core)w/o MMU. The vendor sdk runs freertos on the small core, but it
doesn't prevent users to run other OS such as threadx, zephyr or nommu
linux on the small core. In fact, I sucessfully brought up nommu linux
on the small core. I didn't just send out the patches in time during this
dev window duo to my personal career reason(I spent the time on hunting
for a new job)

I plan to send out NOMMU related patches once 6.9-rc1 is out.

> > > creative build to get everything working, I've never needed to patch
> > > anything in the kernel beyond patching in a custom console for serial
> > > output.
> > >
> >
> > Hey Charles,
> >
> > No worries, we actually did not expected NOMMU to have *so many* users.
> > I guess deprecating stuff is a good way to have immediate feedback ;).
> > Having FDPIC psABI to be merged upstream could also probably be a
> > positive point toward a better NOMMU support.
>
> Ya, that's probably the right way to do it. Touching anything in the psABI
> is pretty miserable, though, so I don't really want to force people to do
> it...
>
> > > I am happy to discuss the possibility of me and or one of the other
> > > RISC-V soft (FPGA) core people stepping up to try to be more active,
> > > but so far we've just been very well serviced by the current NOMMU
> > > Linux setup.
> >
> > It could probably be nice to have some feedback/Tested-by: from NOMMU
> > users for new releases then.
>
> Having more upstream interaction from users is always appreciated, that's
> the best way to prove people are using the code. If you guys have the time
> it'd be great to get this into some sort of CI, ideally running on some real
> platform.

As above, I'd also like to step up on the NOMMU stuff, at least test
nommu on milkv duo's small core. And can be seen from my git commit
histotry, I was active, and I belive I will still be active on riscv linux
kernel development.

>
> > Thanks,
> >
> > Clément
> >
> > >
> > > Charles
> > >
> > >
> > > On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <conor@xxxxxxxxxx> wrote:
> > > >
> > > > On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
> > > > > I guess I could also mark XIP as deprecated.
> > > >
> > > > I'm not so sure, people recently added XIP support to QEMU (and sent
> > > > kernel fixes in December). XIP is also not nearly as much of a problem
> > > > to support, there's far less that it does differently, the main barrier
> > > > was the inability to test it which is no longer the case.
> > > > That said, XIP is gonna kill itself off I feel as it does not support
> > > > runtime patching and therefore is extremely limited on extensions, given
> > > > we use alternatives for all of that (although I suppose if someone has a
> > > > usecase they could make nasty macros worse and implement a compiletime
> > > > switch in the alternatives too).
> > > >
> > > > Cheers,
> > > > Conor.
> > > >
> > > > _______________________________________________
> > > > linux-riscv mailing list
> > > > linux-riscv@xxxxxxxxxxxxxxxxxxx
> > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-riscv