qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Claudio Fontana <claudio.fontana@huawei.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Riku Voipio <riku.voipio@iki.fi>,
	qemu-devel@nongnu.org, patches@linaro.org
Subject: Re: [Qemu-devel] [PATCH 0/2] linux-user: Drop direct use of openat etc syscalls
Date: Wed, 5 Jun 2013 13:17:41 +0200	[thread overview]
Message-ID: <51AF1E55.3000108@huawei.com> (raw)
In-Reply-To: <1370126121-22975-1-git-send-email-peter.maydell@linaro.org>

On 02.06.2013 00:35, Peter Maydell wrote:
> The linux-user syscall emulation layer currently supports the openat
> family of syscalls via two mechanisms: simply calling the corresponding
> libc functions, and making direct syscalls. Since glibc has supported
> these functions since at least glibc 2.5, there's no real need to
> retain the (essentially untested) direct syscall fallback code, so
> this patchset simply deletes it.
> 
> This allows us to remove some ifdeffery that was attempting to disable
> provision of some of the syscalls if the host didn't seem to support
> them, which in some cases was actually wrong. For example where there
> are several flavours of the syscall, we only need one of them, not
> necessarily the exact one the guest has, as with the fstatat* calls.
> And if the guest needs the futimesat() syscall we can provide it
> via glibc, even if that syscall is deprecated or not provided in the
> host (because the host implements utimensat instead). AArch64 in
> particular hits the last of these, which resulted in a compile
> failure due to an unused function, because the syscall implementation's
> ifdef was inconsistent with the ifdef used to define the sys_futimesat()
> function.
> 
> Basically, removing the ugly direct syscall access seemed nicer
> than trying to fix up and render consistent the broken ifdefs :-)
> 
> [RHEL5 has glibc2.5 and provides these functions. RHEL4 did not
> but we don't build on RHEL4 anyhow because its glib is too old.
> uClibc provides these functions.]
> 
> Peter Maydell (2):
>   linux-user: Drop direct use of openat etc syscalls
>   configure: Drop CONFIG_ATFILE test
> 
>  configure            |   26 ------
>  linux-user/syscall.c |  218 ++++++--------------------------------------------
>  2 files changed, 24 insertions(+), 220 deletions(-)
> 

Tested on aarch64 with Foundation v8.

Tested-by: Claudio Fontana <claudio.fontana@huawei.com>

      parent reply	other threads:[~2013-06-05 11:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-01 22:35 [Qemu-devel] [PATCH 0/2] linux-user: Drop direct use of openat etc syscalls Peter Maydell
2013-06-01 22:35 ` [Qemu-devel] [PATCH 1/2] " Peter Maydell
2013-06-01 22:35 ` [Qemu-devel] [PATCH 2/2] configure: Drop CONFIG_ATFILE test Peter Maydell
2013-06-03 15:04 ` [Qemu-devel] [PATCH 0/2] linux-user: Drop direct use of openat etc syscalls Richard Henderson
2013-06-05 11:17 ` Claudio Fontana [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51AF1E55.3000108@huawei.com \
    --to=claudio.fontana@huawei.com \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).