linux-kernel - Re: [RFC] Unify KVM kernel-space and user-space code into a single project

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: <g6xyqstzrxva01v1nlUYAxe124vaj_firegpg@mail.gmail.com>
Date:	Thu, 18 Mar 2010 12:37:40 -0700 (PST)
From:	drepper@...il.com
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Anthony Liguori <anthony@...emonkey.ws>,
	Avi Kivity <avi@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Joerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single project

On Thu, Mar 18, 2010 at 12:15, Ingo Molnar <mingo@...e.hu> wrote:
> I didnt say it's glibc's fault - if then it's more of the kernel's fault as
> most of the complexity is on that side. I said it's due to the fundamental
> distance between the app that makes use of it, the library and the kernel, and
> the resulting difficulties in getting a combined solution out.

This is wrong, too.  Once there is a kernel patch that has a reasonable syscall interface it's easy enough to hack up the glibc side.  Don't try to artificially find an argument to support your thesis.  If kernel developers always need an immediate itch which lives inside the kernel walls to make a change this is a failure of the kernel model and mustn't be "solved" by dragging ever more code into the kernel.

Aside, you don't need a full-fledged glibc implementation for testing.  Especially for AIO it should be usable in much lighter-weight contexts than POSIX AIO.  These wrappers are even more easy to hack up (and have been in the few cases where some code has been produced).

For AIO the situation isn't that the people interested in working on it don't know or care about the use.  Zach (through Oracle's products) is very much interested in the code and knows how it should look like.

Face it, AIO is an example of a complete failure of the kernel developers to provide something usable.  This was the argument and where you started the misdirection of including other projects in the reasoning.
Download attachment "signature.asc" of type "application/pgp-signature" (273 bytes)