Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757385AbbDVFeE (ORCPT ); Wed, 22 Apr 2015 01:34:04 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]:50877 "EHLO mail.sfc.wide.ad.jp" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752587AbbDVFd6 (ORCPT ); Wed, 22 Apr 2015 01:33:58 -0400 Date: Wed, 22 Apr 2015 14:33:55 +0900 Message-ID: From: Hajime Tazaki To: pebolle@tiscali.nl Cc: linux-arch@vger.kernel.org, arnd@arndb.de, corbet@lwn.net, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, netdev@vger.kernel.org, linux-mm@kvack.org, jdike@addtoit.com, richard@nod.at, rusty@rustcorp.com.au, upa@haeena.net, christoph.paasch@gmail.com, mathieu.lacage@gmail.com, libos-nuse@googlegroups.com Subject: Re: [RFC PATCH v3 09/10] lib: libos build scripts and documentation In-Reply-To: <1429562587.14597.80.camel@x220> References: <1429263374-57517-1-git-send-email-tazaki@sfc.wide.ad.jp> <1429450104-47619-1-git-send-email-tazaki@sfc.wide.ad.jp> <1429450104-47619-10-git-send-email-tazaki@sfc.wide.ad.jp> <1429562587.14597.80.camel@x220> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) X-Face: "+?b:_s\r$dbBx'Ur*k#`5|~\>v~i`PzaxANTx_S?J>:mTQrtm:c7'f5b~W2eX~Fl[0Pw,0bow)8r8Z5,D&>]C/'ujqr:fbY>]/52T^Q~cX*y5\?!"i<^Vp=zCNguAeyPH$`ZTv{di25X8,%@! MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5463 Lines: 205 Hi Paul, many thanks for your review. all the fixes will be on next patchset. my comments are below. At Mon, 20 Apr 2015 22:43:07 +0200, Paul Bolle wrote: > > Some random observations while I'm still trying to wrap my head around > all this (which might take quite some time). > > On Sun, 2015-04-19 at 22:28 +0900, Hajime Tazaki wrote: > > --- /dev/null > > +++ b/arch/lib/Kconfig > > @@ -0,0 +1,124 @@ > > +menuconfig LIB > > + bool "LibOS-specific options" > > + def_bool n > > This is the start of the Kconfig parse for lib. (That would basically > still be true even if you didn't set KBUILD_KCONFIG, see below.) So why > not do something like all arches do: > > config LIB > def_bool y > select [...] > > Ie, why would someone want to build for ARCH=lib and still not set LIB? agreed. fixed. > > +config EXPERIMENTAL > > + def_bool y > > Unneeded: removed treewide in, I think, 2014. thanks. fixed. > > +config MMU > > + def_bool n > > Add empty line. > > > +config FPU > > + def_bool n > > Ditto. both are fixed. > > +config KTIME_SCALAR > > + def_bool y > > This one is unused. deleted. > > +config GENERIC_BUG > > + def_bool y > > + depends on BUG > > Add empty line here. fixed. > > +config GENERIC_FIND_NEXT_BIT > > + def_bool y > > This one is unused too. deleted. > > +config SLIB > > + def_bool y > > You've also added SLIB to init/Kconfig in 02/10. But "make ARCH=lib > *config" will never visit init/Kconfig, will it? And, apparently, none > of SL[AOU]B are wanted for lib. So I think the entry for config SLIB in > that file can be dropped (as other arches will never see it because it > depends on LIB). > > (Note that I haven't actually looked into all the Kconfig entries added > above. Perhaps I might do that. But I'm pretty sure most of the time all > I can say is: "I have no idea why this entry defaults to $VALUE".) I intended to SLIB be a generic one, not only for the arch/lib, as we discussed during v2 patch. but, you're right: for the moment, no one uses SLIB, we don't visit init/Kconfig, I dropped config SLIB entry from init/Kconfig. > > +source "net/Kconfig" > > + > > +source "drivers/base/Kconfig" > > + > > +source "crypto/Kconfig" > > + > > +source "lib/Kconfig" > > + > > + > > Trailing empty lines. deleted. thanks. > > diff --git a/arch/lib/Makefile b/arch/lib/Makefile > > new file mode 100644 > > index 0000000..d8a0bf9 > > --- /dev/null > > +++ b/arch/lib/Makefile > > @@ -0,0 +1,251 @@ > > +ARCH_DIR := arch/lib > > +SRCDIR=$(dir $(firstword $(MAKEFILE_LIST))) > > Do you use SRCDIR? no. deleted the line. > > +DCE_TESTDIR=$(srctree)/tools/testing/libos/ > > +KBUILD_KCONFIG := arch/$(ARCH)/Kconfig > > I think you copied this from arch/um/Makefile. But arch/um/ is, well, > special. Why should lib not start the kconfig parse in the file named > Kconfig? And if you want to start in arch/lib/Kconfig, it would be nice > to add a mainmenu (just like arch/x86/um/Kconfig does). right now, 'lib' only wants to eat arch/lib/Kconfig so that build and link its wanted files instead of configurable one. so I beilive arch/lib is also special as arch/um is. I added a mainmenu btw. thanks. > (I don't read Makefilese well enough to understand the rest of this > file. I think it's scary.) indeed. thank you again to review the cryptic files.. > When I did > make ARCH=lib menuconfig > > I saw (among other things): > arch/lib/Makefile.print:41: target `trace/' given more than once in the same rule. > arch/lib/Makefile.print:41: target `trace/' given more than once in the same rule. > arch/lib/Makefile.print:41: target `trace/' given more than once in the same rule. > arch/lib/Makefile.print:41: target `trace/' given more than once in the same rule. > arch/lib/Makefile.print:41: target `lzo/' given more than once in the same rule. (snip) > arch/lib/Makefile.print:41: target `ppp/' given more than once in the same rule. > arch/lib/Makefile.print:41: target `slip/' given more than once in the same rule. > > I have no idea why. Unclean tree? this was due to inappropriate handling of the internal directory listing procedure. fixed. > > +.PHONY : core > > +.NOTPARALLEL : print $(subdirs) $(final-obj-m) > > > --- /dev/null > > +++ b/arch/lib/processor.mk > > @@ -0,0 +1,7 @@ > > +PROCESSOR=$(shell uname -m) > > +PROCESSOR_x86_64=64 > > +PROCESSOR_i686=32 > > +PROCESSOR_i586=32 > > +PROCESSOR_i386=32 > > +PROCESSOR_i486=32 > > +PROCESSOR_SIZE=$(PROCESSOR_$(PROCESSOR)) > > The rest of the tree appears to use BITS instead of PROCESSOR_SIZE. And > I do hope there's a cleaner way for lib to set PROCESSOR_SIZE than this. the variable PROCESSOR_SIZE is only used by arch/lib/Makefile, with the following lines. > +ifeq ($(PROCESSOR_SIZE),64) > +CFLAGS+= -DCONFIG_64BIT > +endif Thus it eventually uses CONFIG_64BIT. I think a cleaner way is to follow the way of arch/um, like below: I deleted processor.mk and PROCESSOR_SIZE variable. ifeq ($(SUBARCH),x86) ifeq ($(shell uname -m),x86_64) CFLAGS+= -DCONFIG_64BIT endif though it's not able to cross-compile yet. again, thank you so much. I'll be back very soon (v4 patch). -- Hajime -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/