From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LPDaO-00070B-1U
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:11:56 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LPDaM-0006xy-8T
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:11:55 -0500
Received: from [199.232.76.173] (port=51971 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LPDaL-0006xg-TT
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:11:54 -0500
Received: from mx2.redhat.com ([66.187.237.31]:38769)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1LPDaL-0002A4-GA
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:11:53 -0500
Message-ID: <4975A2E8.9090602@redhat.com>
Date: Tue, 20 Jan 2009 12:09:44 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API
References: <1232308399-21679-1-git-send-email-avi@redhat.com>	<4974943B.4020507@redhat.com>
	<49749EC5.3080704@codemonkey.ws>	<200901191618.10082.paul@codesourcery.com>	<4974AB48.1070301@codemonkey.ws>
	<4974ACD0.601@redhat.com> <4974D154.5010601@codemonkey.ws>
In-Reply-To: <4974D154.5010601@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Paul Brook <paul@codesourcery.com>

Anthony Liguori wrote:
>>> Those two functions can live in exec.c too.  The nice thing about 
>>> using map() is that it's easily overriden and chained.  So what I'm 
>>> proposing.
>>>
>>> cpu_physical_memory_map()
>>> cpu_physical_memory_unmap()
>>
>> This should be the baseline API with the rest using it.
>
> Yup.
>
>>> do_streaming_IO(map, unmap, ioworker, opaque);
>>
>> Why pass map and unmap?
>
> Because we'll eventually have:
>
> pci_device_memory_map()
> pci_device_memory_unmap()
>
> In the simplest case, pci_device_memory_map() just calls 
> cpu_physical_memory_map().  But it may do other things.

Let's start without those callbacks, until those "other things" reveal 
themselves.

>>> do_packet_IO(map, unmap, buffer, size, ioworker, opaque);
>>
>> If you pass the buffer then the device needs to allocate large 
>> amounts of bounce memory.
>
> If do_packet_IO took a buffer, instead of calling alloc_buffer(size) 
> when map fails (you run out of bounce memory), you simply use buffer.  
> Otherwise, alloc_buffer() must be able to allocate enough memory to 
> satisfy any request.
>
> Since each packet device knows it's maximum size up front, it makes 
> sense for the device to allocate it.  You could also not care and just 
> trust that callers do the right thing.
>

Pushing things to the caller complicates all callers.  This isn't the 
ideal solution.

-- 
error compiling committee.c: too many arguments to function