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

[Hajime Tazaki]

Hello,

sorry for the late response.

On Sat, 10 Oct 2020 01:06:03 +0900,
Johannes Berg wrote:
> 
> 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?

Okay, we won't use the -j flag at this place.

> > > > --- /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 ...

We're trying to reimplement atomic64 ops with gcc builtins.

We're now trying to address all of comments we got, and will get here
back once we have done.

-- Hajime