[Qemu-devel] [PATCH] memory: fix return value on unassigned reads

[Qemu-devel] [PATCH] memory: fix return value on unassigned reads

[Avi Kivity]

The memory API returns -1 on unassigned reads, different from the original
in exec.c, which returned zero.  This breaks grlib_uart; apparently some
users depend on it.

Fix by returning zero; however if reading from the uart is legal, then it
should be modified to accept reads.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 memory.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/memory.c b/memory.c
index ee4c98a..afc12dc 100644
--- a/memory.c
+++ b/memory.c
@@ -917,7 +917,7 @@ static uint64_t memory_region_dispatch_read1(MemoryRegion *mr,
     uint64_t data = 0;
 
     if (!memory_region_access_valid(mr, addr, size, false)) {
-        return -1U; /* FIXME: better signalling */
+        return 0; /* FIXME: better signalling */
     }
 
     if (!mr->ops->read) {
-- 
1.7.7.1

Re: [Qemu-devel] [PATCH] memory: fix return value on unassigned reads

[Fabien Chouteau]

On 26/01/2012 10:33, Avi Kivity wrote:
> The memory API returns -1 on unassigned reads, different from the original
> in exec.c, which returned zero.

Isn't this return value platform specific?

> This breaks grlib_uart; apparently some users depend on it.
> 
> Fix by returning zero; however if reading from the uart is legal, then
> it should be modified to accept reads.
> 

That's right, grlib_uart depends on it because I took the easy (lazy?)
way. I will send a patch to handle reads to UART's registers.

-- 
Fabien Chouteau

Re: [Qemu-devel] [PATCH] memory: fix return value on unassigned reads

[Avi Kivity]

On 01/26/2012 01:31 PM, Fabien Chouteau wrote:
> On 26/01/2012 10:33, Avi Kivity wrote:
> > The memory API returns -1 on unassigned reads, different from the original
> > in exec.c, which returned zero.
>
> Isn't this return value platform specific?

Maybe (and I think ~0 is the common one); the patch just restores the
previous behaviour.

>
> > This breaks grlib_uart; apparently some users depend on it.
> > 
> > Fix by returning zero; however if reading from the uart is legal, then
> > it should be modified to accept reads.
> > 
>
> That's right, grlib_uart depends on it because I took the easy (lazy?)
> way. I will send a patch to handle reads to UART's registers.

Definitely that's the best way to fix the problem.

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