[RFC v7 08/21] um: add nommu mode for UML library mode

[Johannes Berg]

On Fri, 2020-10-09 at 12:38 +0900, Hajime Tazaki wrote:
> 
> > > +++ b/arch/um/nommu/Makefile.um
> > 
> > [...]
> > 
> > > +ifeq ($(shell uname -s), Linux)
> > > +NPROC=$(shell nproc)
> > > +else # e.g., FreeBSD
> > > +NPROC=$(shell sysctl -n hw.ncpu)
> > > +endif
> > 
> > That seems very inappropriate here.
> 
> Will cut the FreeBSD part.

But even the NPROC and -j flag mangling seems ... awful?

> > > --- /dev/null
> > > +++ b/arch/um/nommu/include/asm/atomic64.h
> > 
> > That doesn't make sense to me, you can control CONFIG_GENERIC_ATOMIC64
> > to be on, and don't need the ifdef and this file?
> 
> We were suggested to not use GENERIC_ATOMIC64 on 64bit build during
> our v3 patchset.  So we actually control CONFIG_GENERIC_ATOMIC64 to be
> on only when !64BIT, and thus need atomic64.h for the 64BIT build.
> 
> https://lwn.net/ml/linux-arch/20200205093454.GG14879@hirez.programming.kicks-ass.net/

Well, yeah, but your architecture _is_ a piece of crap in needing
atomic64 emulation? :-)

How about just using the real atomic64 implementation like UML normally
does? I mean, falling back to the actual underlying CPU. Or even gcc
intrinsics?

You've basically re-implemented CONFIG_GENERIC_ATOMIC64, so perhaps
you've hidden it from PeterZ's view now because you're no longer
touching the real generic atomic64 (which is for 32-bit machines), but
that doesn't actually make this any *better*. Arguably *worse* since
you've just copied it ...

> > > +++ b/arch/um/nommu/um/delay.c
> > 
> > why the double um/ path?
> 
> This is because now in arch/um/Makefile,
> 
>  - SUBARCH := um/nommu
>  - HEADER_ARCH := $(SUBARCH)
>  - HOST_DIR := arch/$(HEADER_ARCH)
>  - core-y += $(HOST_DIR)/um
> 
> the last line expands as arch/um/nommu/um.

But is there a reason for it? Couldn't it be changed?

Anyway, we're still debating the whole build system and layout so not
much point in going into the details now ...

johannes