Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: correct argument number for sys_mremap and sys_splice

[Petar Jovanovic]

________________________________________
From: Peter Maydell address@hidden
Sent: Tuesday, July 23, 2013 7:33 PM
To: Michael Tokarev
Cc: Petar Jovanovic; address@hidden; address@hidden; address@hidden; Petar 
Jovanovic
Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH] linux-user: correct argument 
number for sys_mremap and sys_splice

> Petar: I think it would be a good idea if you checked
> the whole of our table against a recent kernel and made
> sure we're in sync for everything, rather than fixing
> things one at a time.
>

I did, this is how I came up with these two system calls.

Here are all the differences:

Syscall             Qemu    Kernel

sys_acct            0    1
sys_epoll_wait      3    4
sys_fdatasync       0    1
sys_lookup_dcookie  3    4
sys_mremap          4    5
sys_quotactl        0    4
sys_sigaltstack     2    0
sys_splice          4    6
sys_waitid          4    5


So, we are not fully in sync, but the rest of it will not cause any
problems. In the existing QEMU code in cpu_loop(CPUMIPSState *env)
first four arguments are always passed, so for sys_acct, sys_epoll_wait,
sys_fdatasync, sys_quotactl, sys_lookup_dcookie and sys_sigaltstack
the differences do not matter.

For sys_splice and sys_mremap, the difference is important so I
added this change and came up with test cases.

The last on the list is sys_waitid, the difference could be important yet
it still is not, since the host part does not seem to make use of it.

Considering the turn-around times for code reviews and getting the changes
in, I am guided by "If it ain't broke, don't fix it", otherwise I would
change the other values for clarity and readability, I would also change
tabs/spaces mix in the table mips_syscall_args, etc.

Regards,
Petar