From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:53702)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1ShHca-00030r-Oo
	for qemu-devel@nongnu.org; Wed, 20 Jun 2012 05:54:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1ShHcW-00069j-68
	for qemu-devel@nongnu.org; Wed, 20 Jun 2012 05:54:44 -0400
Received: from mx1.redhat.com ([209.132.183.28]:38696)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1ShHcV-00069K-U3
	for qemu-devel@nongnu.org; Wed, 20 Jun 2012 05:54:40 -0400
Message-ID: <4FE19DD6.9060707@redhat.com>
Date: Wed, 20 Jun 2012 11:54:30 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1340087992-2399-1-git-send-email-benh@kernel.crashing.org>
	<1340087992-2399-8-git-send-email-benh@kernel.crashing.org>
	<4FE081CE.1060001@redhat.com> <1340137438.28143.28.camel@pasglop>
	<20120620031421.GB9144@truffala.fritz.box>
	<4FE16CC6.6090007@redhat.com> <1340184341.28143.144.camel@pasglop>
In-Reply-To: <1340184341.28143.144.camel@pasglop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 07/13] usb: Convert usb_packet_{map,
 unmap} to universal DMA helpers
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: qemu-devel@nongnu.org, anthony@codemonkey.ws

  Hi,

> [ lots of interesting background info snipped ]

> It's all doable, it's also a bit tricky, potentially quite a bit of
> code, new KVM/qemu interfaces, etc... for a problem that's going to be a
> non-issue pretty much 99.9% of the time :-) We still need to address it,
> but I haven't convinced myself yet that I have come up with the best
> solution :-)

Yea, sure, it's in the "nice-to-have" not "must-have" category.  And
adding complex code which almost never actually runs needs some care
indeed.  Not having that for the initial merge is perfectly fine with
me, just wanted to know what dragons might be lurking there ;)

Oh, and: Acked-by: Gerd Hoffmann <kraxel@redhat.com>

cheers,
  Gerd