Sure, Peter, I am going to take your hints and address all your concerns in the v2 of this series, which is planned to be posted soon.
I appreciate your guidance, Aleksandar ________________________________________ From: Peter Maydell [peter.mayd...@linaro.org] Sent: Wednesday, October 05, 2016 5:38 AM To: Aleksandar Markovic Cc: Aleksandar Markovic; Riku Voipio; QEMU Developers; Laurent Vivier; Miodrag Dinic; Aleksandar Rikalo; Petar Jovanovic; Yongbok Kim; Leon Alrae; Aurelien Jarno Subject: Re: [Qemu-devel] [PATCH 4/4] linux-user: Fix fadvise64() syscall support for Mips32 On 5 October 2016 at 03:02, Aleksandar Markovic <aleksandar.marko...@imgtec.com> wrote: > Yes, we could replace TARGET_NR_fadvise64 with TARGET_NR_fadvise64_64 > in Mips32 syscall numbers definition list, and expect the same effect. > I just prefer to leave original symbols for syscall numbers, as they > are defined in kernel headers, unless there is a compelling reason not > to do it. I see the argument, but the reason would be "you end up reimplementing fadvise64_64 as a special case for MIPS for fadvise64, which is a chunk of extra ugly code that really isn't necessary". > But, there is more. Code that handles TARGET_NR_fadvise64_64 in Qemu > utilizes host's posix_advise(). It looks to me that this is just > plain incorrect. It won't work correctly on 32 bit hosts, with > respect to arguments of posix_advise() that are 32-bit (while > 64-bit value is passed to them) Instead, posix_fadvise64() should > have been used, IMHO. If this is broken we should fix it rather than just ignoring it for MIPS, but I don't think it is broken -- we compile QEMU with -DFILE_OFFSET_BITS=64, so posix_fadvise() always takes 64 bit arguments even on 32 bit hosts. thanks -- PMM
