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
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 fi
On Fri, 25 Oct 2024 18:11:01 +0900,
Johannes Berg wrote:
>
> (I should say, I'm still reading through this, and haven't formed an
> overall opinion. Just nitpicking on the details as I see them for now)
thanks anyway. looking forward to any opinions.
> > +#endif
> > +
> >
> > #include
>
(I should say, I'm still reading through this, and haven't formed an
overall opinion. Just nitpicking on the details as I see them for now)
> +#endif
> +
>
> #include
extra newline
> /* tlb.c */
> +#ifdef CONFIG_MMU
> extern void report_enomem(void);
> +#else
> +static inline void report_e
This commit adds memory operations on UML under !MMU environment.
Some part of the original UML code relying on CONFIG_MMU are excluded
from compilation when !CONFIG_MMU. Additionally, generic functions such as
uaccess, futex, memcpy/strnlen/strncpy can be used as user- and
kernel-space share the
