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]

Date:	Mon, 30 Mar 2015 00:06:10 +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, mathieu.lacage@...il.com
Subject: Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS)

Hi Richard,

At Fri, 27 Mar 2015 10:21:59 +0100,
Richard Weinberger wrote:

> Just an idea popping out of my head...
> 
> What about putting libos into tools/testing/ and make it much more generic and framework alike.

it's trivial though, libos is not only for the testing (i.e., NUSE).
# of course tools/libos or something can be the place.

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

the issue here is the decision between 'no-ops' and
'assert(false)' depends on the context. an auto-generated
mechanism needs some hand-written parameters I think.

one more concern on the out-of-arch-tree design is that how
to handle our asm-generic-based header files
(arch/lib/include/asm). we have been heavily used
'generic-y' in the Kbuild file to reuse header files.

OTOH, I agree with you on the point of auto-generated glues
(stubs), or trying to avoid glues (reuse the originals as
much as possible) as Antti mentioned. that will definitely
be reduce the amount of maintenance effort.

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