[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m2pp6tonxa.wl@sfc.wide.ad.jp>
Date: Fri, 24 Apr 2015 18:50:25 +0900
From: Hajime Tazaki <tazaki@....wide.ad.jp>
To: richard@....at
Cc: linux-arch@...r.kernel.org, arnd@...db.de, corbet@....net,
cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
netdev@...r.kernel.org, linux-mm@...ck.org, jdike@...toit.com,
rusty@...tcorp.com.au, upa@...ena.net, christoph.paasch@...il.com,
mathieu.lacage@...il.com, libos-nuse@...glegroups.com
Subject: Re: [RFC PATCH v3 00/10] an introduction of library operating system for Linux (LibOS)
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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists