Re: m68k Kconfig warning

[Mike Rapoport <rppt@linux.ibm.com>]

On Mon, Dec 02, 2019 at 02:32:28PM +0100, Geert Uytterhoeven wrote:
> Hi Kars,.
> 
> On Mon, Dec 2, 2019 at 12:42 PM Kars de Jong <karsdejong@home.nl> wrote:
> > Op wo 27 nov. 2019 om 08:12 schreef Geert Uytterhoeven <geert@linux-m68k.org>:
> > > On Wed, Nov 27, 2019 at 2:27 AM Randy Dunlap <rdunlap@infradead.org> wrote:
> > > > Just noticed this.  I don't know what the right fix is.
> > > > Would you take care of it, please?
> > > >
> > > > on Linux 5.4, m68k allmodconfig:
> > > >
> > > > WARNING: unmet direct dependencies detected for NEED_MULTIPLE_NODES
> > > >   Depends on [n]: DISCONTIGMEM [=n] || NUMA
> > > >   Selected by [y]:
> > > >   - SINGLE_MEMORY_CHUNK [=y] && MMU [=y]
> > >
> > > This has been basically there forever, but working.
> >
> > The reason for SINGLE_MEMORY_CHUNK depending on NEED_MULTIPLE_NODES is
> > historic due to the way it is implemented.
> > I played with it this weekend and I got a working version of FLATMEM,
> > which can replace SINGLE_MEMORY_CHUNK.
> 
> Nice, thanks!
> 
> > step might be to replace DISCONTIGMEM with SPARSEMEM (since
> > DISCONTIGMEM has been deprecated).
> 
> Mike Rapoport has patches for that:
> "[PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM"
> 
> Unfortunately they're not on lore, and there were some issues with them.

The patches are here:
https://www.spinics.net/lists/linux-m68k/msg13588.html

Aside from some technicalities we had troubles deciding what should be the
section size. With larger section size we might end up with wasted memory
for memory maps and with smaller section size we'll have to limit the
addressable physical memory...


> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

-- 
Sincerely yours,
Mike.