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

Date:	Fri, 27 Mar 2015 10:21:59 +0100
From:	Richard Weinberger <richard@....at>
To:	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, linux-mm@...ck.org, jdike@...toit.com,
	rusty@...tcorp.com.au, mathieu.lacage@...il.com
Subject: Re: [RFC PATCH 00/11] an introduction of library operating system
 for Linux (LibOS)

Am 27.03.2015 um 07:34 schrieb Hajime Tazaki:
>>> it (arch/lib) is a hardware-independent architecture which
>>> provides necessary features to the remainder of kernel code,
>>> isn't it ?
>>
>> The stuff in arch/ is the code to glue the kernel to
>> a specific piece of hardware.
>> Your code does something between. You duplicate kernel core features
>> to make a specific piece of code work in userland.
> 
> indeed, 'something between' would be an appropriate word.

Just an idea popping out of my head...

What about putting libos into tools/testing/ and make it much more generic and framework alike.
With more generic I mean that libos could be a stubbing framework for the kernel.
i.e. you specify the subsystem you want to test/stub and the framework helps you doing so.
A lot of the stubs you're placing in arch/lib could be auto-generated as the
vast majority of all kernel methods you stub are no-ops which call only lib_assert(false).

Using that approach only very few kernel core components have to be duplicated and
actually implemented by hand.
Hence, less maintenance overhead and libos is not broken all the time.

What do you think?

Thanks,
//richard
--
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