lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists