linux-kernel - Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS)

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]

Message-ID: <55182F8E.3020606@iki.fi>
Date:	Sun, 29 Mar 2015 16:59:58 +0000
From:	Antti Kantee <pooka@....fi>
To:	Richard Weinberger <richard@....at>,
	Hajime Tazaki <tazaki@...e.ad.jp>
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
Subject: Re: [RFC PATCH 00/11] an introduction of library operating system
 for Linux (LibOS)

On 28/03/15 21:17, Richard Weinberger wrote:
> Am 27.03.2015 um 16:17 schrieb Antti Kantee:
>> Let me try to offer some insight.  I've been working on something similar in mainline NetBSD for almost 8 years now, so in addition to ideas popping into my head I've also tested
>> them out in the real world.  I do think that all operating systems should be structured to support a lib mode, and hopefully integrating Hajime's work into Linux will get on the
>> right track.
>
> IMHO it depends on the maintenance burden.
> Linux source changes magnitudes faster than NetBSD's.

I can understand why you're worried about maintenance burden -- believe 
me, I've heard all the excuses before, starting all the way back from 
"it's impossible".  Let's dissect your concern.

There's a reason I wrote in my original mail: "Figuring out how to make 
the libos as close to zero-maintenance as possible is indeed the trick". 
  It took me a few weeks to make things work in my version, but it took 
four years to figure out how to make things as maintainable as I could 
figure out how to make them.  The good news is that the results of those 
four years are more or less generic and independent of OS.

The source may change an order of magnitude faster in Linux, but Linux 
also has several orders of magnitude more resources.  Even if you do not 
believe that available resources are relevant in the equation, you can 
still take the data from NetBSD, multiply the maintenance burden with 
any Stetson-Harrison constant you see fit, and have your expected Linux 
maintenance burden value.

Mind game: what if I were to assert that the maintenance burden of 
application compatibility is too high on Linux compared to NetBSD due to 
the high rate of change?  I think everyone would rush to tell me that 
I'm wrong...

So why not just evaluate Hajime et al's work for its functional merits 
and immediate benefits, and see how maintenance burden plays out by 
collecting actual data on it.

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