From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753279AbbC2PGT (ORCPT ); Sun, 29 Mar 2015 11:06:19 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]:51343 "EHLO mail.sfc.wide.ad.jp" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752734AbbC2PGP (ORCPT ); Sun, 29 Mar 2015 11:06:15 -0400 Date: Mon, 30 Mar 2015 00:06:10 +0900 Message-ID: From: Hajime Tazaki To: richard@nod.at 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, rusty@rustcorp.com.au, mathieu.lacage@gmail.com Subject: Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS) In-Reply-To: <55152137.20405@nod.at> References: <1427202642-1716-1-git-send-email-tazaki@sfc.wide.ad.jp> <551164ED.5000907@nod.at> <55117565.6080002@nod.at> <55118277.5070909@nod.at> <55133BAF.30301@nod.at> <5514560A.7040707@nod.at> <55152137.20405@nod.at> 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 Hi Richard, At Fri, 27 Mar 2015 10:21:59 +0100, Richard Weinberger wrote: > Just an idea popping out of my head... > > What about putting libos into tools/testing/ and make it much more generic and framework alike. it's trivial though, libos is not only for the testing (i.e., NUSE). # of course tools/libos or something can be the place. > With more generic I mean that libos could be a stubbing framework for the kernel. > i.e. you specify the subsystem you want to test/stub and the framework helps you doing so. > A lot of the stubs you're placing in arch/lib could be auto-generated as the > vast majority of all kernel methods you stub are no-ops which call only lib_assert(false). the issue here is the decision between 'no-ops' and 'assert(false)' depends on the context. an auto-generated mechanism needs some hand-written parameters I think. one more concern on the out-of-arch-tree design is that how to handle our asm-generic-based header files (arch/lib/include/asm). we have been heavily used 'generic-y' in the Kbuild file to reuse header files. OTOH, I agree with you on the point of auto-generated glues (stubs), or trying to avoid glues (reuse the originals as much as possible) as Antti mentioned. that will definitely be reduce the amount of maintenance effort. -- Hajime From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by kanga.kvack.org (Postfix) with ESMTP id 11CC8900015 for ; Sun, 29 Mar 2015 11:06:15 -0400 (EDT) Received: by pacwe9 with SMTP id we9so142779515pac.1 for ; Sun, 29 Mar 2015 08:06:14 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp. [2001:200:0:8803::53]) by mx.google.com with ESMTPS id r3si11146552pdc.28.2015.03.29.08.06.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Mar 2015 08:06:13 -0700 (PDT) Date: Mon, 30 Mar 2015 00:06:10 +0900 Message-ID: From: Hajime Tazaki Subject: Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS) In-Reply-To: <55152137.20405@nod.at> References: <1427202642-1716-1-git-send-email-tazaki@sfc.wide.ad.jp> <551164ED.5000907@nod.at> <55117565.6080002@nod.at> <55118277.5070909@nod.at> <55133BAF.30301@nod.at> <5514560A.7040707@nod.at> <55152137.20405@nod.at> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: richard@nod.at 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, rusty@rustcorp.com.au, mathieu.lacage@gmail.com Hi Richard, At Fri, 27 Mar 2015 10:21:59 +0100, Richard Weinberger wrote: > Just an idea popping out of my head... > > What about putting libos into tools/testing/ and make it much more generic and framework alike. it's trivial though, libos is not only for the testing (i.e., NUSE). # of course tools/libos or something can be the place. > With more generic I mean that libos could be a stubbing framework for the kernel. > i.e. you specify the subsystem you want to test/stub and the framework helps you doing so. > A lot of the stubs you're placing in arch/lib could be auto-generated as the > vast majority of all kernel methods you stub are no-ops which call only lib_assert(false). the issue here is the decision between 'no-ops' and 'assert(false)' depends on the context. an auto-generated mechanism needs some hand-written parameters I think. one more concern on the out-of-arch-tree design is that how to handle our asm-generic-based header files (arch/lib/include/asm). we have been heavily used 'generic-y' in the Kbuild file to reuse header files. OTOH, I agree with you on the point of auto-generated glues (stubs), or trying to avoid glues (reuse the originals as much as possible) as Antti mentioned. that will definitely be reduce the amount of maintenance effort. -- Hajime -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org