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: <20100318201826.GA20588@elte.hu>
Date:	Thu, 18 Mar 2010 21:18:26 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	drepper@...il.com
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

* drepper@...il.com <drepper@...il.com> wrote:

> 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. [...]

Where 'reasonable' is defined by you, right?

As i said, the KAIO situation is mostly the kernel's fault, but you are a 
pretty passive and unhelpful entity in this matter too, arent you?

For example, just to state the obvious: libaio has been written 8 years ago in 
2002 and has been used in apps early on. Why arent those kernel APIs, while 
not being a full/complete solution, supported by glibc, and wrapped to 
pthreads based emulation on kernels that dont support it?

I'm not talking about a 100% full POSIX AIO implementation (the kernel side is 
not complete enough for that) - i'm just talking about the APIs that libaio 
and the kernel supports today.

Why isnt glibc itself making use of those AIO capabilities internally? (even 
if it's not possible to support full POSIX AIO)

I checked today's glibc repo, and there's no sign of any of that:

 glibc> git grep io_submit 
 glibc> git grep aio_context_t 
 glibc> 

Zero, nil, nada.

Getting _something_ into glibc would certainly help move the situation. Glibc 
itself using existing KAIO bits internally would help too and dont tell me 
it's 100% unusable: it's certainly capable enough to run DB servers. glibc 
using it would create further demand (and pressure, and incentives) for 
improvements.

There were even glibc patches created by Ben LaHaise for some of these bits, 
IIRC.

One can certainly make the argument that glibc not using _any_ of the current 
KAIO capabilities harms its further development.

> [...] Don't try to artificially find an argument to support your thesis.

Charming argumentation style, i really missed it.

Thanks,

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