|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API |
Date: | Tue, 20 Jan 2009 12:09:44 +0200 |
User-agent: | Thunderbird 2.0.0.19 (X11/20090105) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |