[RFC PATCH 03/13] um: nommu: memory handling
Hajime Tazaki
thehajime at gmail.com
Sat Oct 26 00:24:51 PDT 2024
On Sat, 26 Oct 2024 00:15:06 +0900,
Johannes Berg wrote:
>
> On Fri, 2024-10-25 at 21:55 +0900, Hajime Tazaki wrote:
> > >
> > > Should that really do _nothing_? Perhaps it's not called at all in no-
> > > MMU, but then you don't need it, but otherwise it seems it should do
> > > something even if it's just panic()?
> >
> > it is called also in !MMU. I'll think to figure out how the function
> > is shared.
>
> Feels like it should do something then? Why not print like before? If it
> happens in userspace we kill it, otherwise not sure what even happens...
the function report_enomem() is defined in tlb.c, used in several
places (trap.c, os-Linux/skas/process.c) but in !MMU the tlb.c
is filtered-out from compilation but uses trap.c so, it causes missing
symbols.
I can move the report_enomem() function to somewhere else, like mem.c,
but all the current usage of report_enomem() is MMU dependent
procedure so, I thought it is fine without doing anything.
> > > mmap64(....
> > > MAP_SHARED | MAP_FIXED |
> > > IS_ENABLED(CONFIG_MMU) ? MAP_ANONYMOUS : 0,
> > > ...);
> >
> > since this is part under os-Linux and we cannot use kconfig.h (IIUC)
> > feature (e.g., IS_ENABLED). but I'll reformat it to simplify instead
> > of duplicating same lines.
>
> Oh, missed that, sorry
>
> still I guess putting
>
> #ifndef CONFIG_MMU
> | MAP_ANONYMOUS
> #endif
>
> might be nicer.
I thought the same thing. Will fix it.
-- Hajime
More information about the linux-um
mailing list