From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by kanga.kvack.org (Postfix) with ESMTP id B44976B006C for ; Fri, 24 Apr 2015 05:50:29 -0400 (EDT) Received: by pdbqa5 with SMTP id qa5so44476044pdb.1 for ; Fri, 24 Apr 2015 02:50:29 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp. [203.178.142.130]) by mx.google.com with ESMTPS id pk3si16650892pbc.135.2015.04.24.02.50.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Apr 2015 02:50:28 -0700 (PDT) Date: Fri, 24 Apr 2015 18:50:25 +0900 Message-ID: From: Hajime Tazaki Subject: Re: [RFC PATCH v3 00/10] an introduction of library operating system for Linux (LibOS) In-Reply-To: <553A05E9.7040601@nod.at> References: <1429263374-57517-1-git-send-email-tazaki@sfc.wide.ad.jp> <1429450104-47619-1-git-send-email-tazaki@sfc.wide.ad.jp> <5539F370.9070704@nod.at> <553A05E9.7040601@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, upa@haeena.net, christoph.paasch@gmail.com, mathieu.lacage@gmail.com, libos-nuse@googlegroups.com At Fri, 24 Apr 2015 10:59:21 +0200, Richard Weinberger wrote: > Am 24.04.2015 um 10:22 schrieb Hajime Tazaki: > >> You *really* need to shape up wrt the build process. > > > > at the moment, the implementation of libos can't automate to > > follow such changes in the build process. but good news is > > it's a trivial task to follow up the latest function. > > > > my observation on this manual follow up since around 3.7 > > kernel (2.5 yrs ago) is that these changes mostly happened > > during merge-window of each new version, and the fix only > > takes a couple of hours at maximum. > > > > I think I can survive with these changes but I'd like to ask > > broader opinions. > > > > > > one more question: > > > > I'd really like to have a suggestion on which tree I should > > base for libos tree. > > > > I'm proposing a patchset to arnd/asm-generic tree (which I > > believe the base tree for new arch/), while the patchset is > > tested with davem/net-next tree because right now libos is > > only for net/. > > > > shall I propose a patchset based on Linus' tree instead ? > > I'd suggest the following: > Maintain LibOS in your git tree and follow Linus' tree. I see. will do it from next patch version. > Make sure that all kernel releases build and work. > > This way you can experiment with automation and other > stuff. If it works well you can ask for mainline inclusion > after a few kernel releases. > > Your git history will show how much maintenance burden > LibOS has and how much with every merge window breaks and > needs manual fixup. I believe this experiment is what we have been doing in the past a couple of years (it's been tested with net-next tree, not Linus tree though). and the experiment is working well (as I stated in the previous email) and that's why I'm here to propose this patchset. you can also see the git history: it also includes libos specific commits of course. https://github.com/libos-nuse/net-next-nuse/commits/nuse?author=thehajime -- 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