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
| ||
|
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