All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Vivier <laurent@vivier.eu>
To: Alistair Francis <alistair23@gmail.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	"open list:RISC-V" <qemu-riscv@nongnu.org>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2 2/2] linux-user/riscv: Update the syscall_nr's to the 5.5 kernel
Date: Thu, 27 Feb 2020 01:41:05 +0100	[thread overview]
Message-ID: <04072aaf-320b-9f23-d3a7-82df223806ba@vivier.eu> (raw)
In-Reply-To: <CAKmqyKM+nmUwr65i8keu578wLfMappj-9yUJHg+rO44+_YVz6w@mail.gmail.com>

Le 27/02/2020 à 01:10, Alistair Francis a écrit :
> On Wed, Feb 26, 2020 at 4:02 PM Laurent Vivier <laurent@vivier.eu> wrote:
>>
>> Le 26/02/2020 à 20:32, Alistair Francis a écrit :
>>> On Tue, Feb 25, 2020 at 3:50 AM Laurent Vivier <laurent@vivier.eu> wrote:
>>>>
>>>> Le 25/02/2020 à 00:21, Alistair Francis a écrit :
>>>>> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
>> ...
>>>> I think you can remove following defintion as they should be translated
>>>> by the target glibc.
>>>
>>> glibc won't be exposing these externally, the current plan is just to
>>> use this internally to glibc.
>>
>> But if they are defined internally to glibc, glibc will always translate
>> the older ones to the 64bit ones and thus glibc will never use the older
>> ones with the kernel, only the 64bit ones, thus the older syscalls
>> should never come to QEMU.
> 
> That's part of the problem. QEMU has no TARGET_NR_futex_time64
> support, so we define TARGET_NR_futex to be TARGET_NR_futex_time64.

Ok, I understand the problem.

> Looking a bit more it looks like there will still be issues as the
> syscall.c makes assumptions on time_t and friends being the word
> length (which isn't true for RV32), but this is at least a step in the
> right direction.
> 
> Would it be possible to define the type sizes per architecture like glibc does?

The best to do is to define the TARGET_NR_XXX_time64, it will be
beneficial for all the targets.

We already have functions host_to_target_timespec(),
host_to_target_timespec64() and a target__kernel_timespec with 64bit fields.

Thanks,
Laurent


WARNING: multiple messages have this Message-ID (diff)
From: Laurent Vivier <laurent@vivier.eu>
To: Alistair Francis <alistair23@gmail.com>
Cc: "open list:RISC-V" <qemu-riscv@nongnu.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2 2/2] linux-user/riscv: Update the syscall_nr's to the 5.5 kernel
Date: Thu, 27 Feb 2020 01:41:05 +0100	[thread overview]
Message-ID: <04072aaf-320b-9f23-d3a7-82df223806ba@vivier.eu> (raw)
In-Reply-To: <CAKmqyKM+nmUwr65i8keu578wLfMappj-9yUJHg+rO44+_YVz6w@mail.gmail.com>

Le 27/02/2020 à 01:10, Alistair Francis a écrit :
> On Wed, Feb 26, 2020 at 4:02 PM Laurent Vivier <laurent@vivier.eu> wrote:
>>
>> Le 26/02/2020 à 20:32, Alistair Francis a écrit :
>>> On Tue, Feb 25, 2020 at 3:50 AM Laurent Vivier <laurent@vivier.eu> wrote:
>>>>
>>>> Le 25/02/2020 à 00:21, Alistair Francis a écrit :
>>>>> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
>> ...
>>>> I think you can remove following defintion as they should be translated
>>>> by the target glibc.
>>>
>>> glibc won't be exposing these externally, the current plan is just to
>>> use this internally to glibc.
>>
>> But if they are defined internally to glibc, glibc will always translate
>> the older ones to the 64bit ones and thus glibc will never use the older
>> ones with the kernel, only the 64bit ones, thus the older syscalls
>> should never come to QEMU.
> 
> That's part of the problem. QEMU has no TARGET_NR_futex_time64
> support, so we define TARGET_NR_futex to be TARGET_NR_futex_time64.

Ok, I understand the problem.

> Looking a bit more it looks like there will still be issues as the
> syscall.c makes assumptions on time_t and friends being the word
> length (which isn't true for RV32), but this is at least a step in the
> right direction.
> 
> Would it be possible to define the type sizes per architecture like glibc does?

The best to do is to define the TARGET_NR_XXX_time64, it will be
beneficial for all the targets.

We already have functions host_to_target_timespec(),
host_to_target_timespec64() and a target__kernel_timespec with 64bit fields.

Thanks,
Laurent


  reply	other threads:[~2020-02-27  0:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-24 23:21 [PATCH v2 0/2] linux-user: generate syscall_nr.sh for RISC-V Alistair Francis
2020-02-24 23:21 ` Alistair Francis
2020-02-24 23:21 ` [PATCH v2 1/2] linux-user: Protect more syscalls Alistair Francis
2020-02-24 23:21   ` Alistair Francis
2020-02-25 11:59   ` Laurent Vivier
2020-02-25 11:59     ` Laurent Vivier
2020-02-26  0:43     ` Alistair Francis
2020-02-26  0:43       ` Alistair Francis
2020-02-24 23:21 ` [PATCH v2 2/2] linux-user/riscv: Update the syscall_nr's to the 5.5 kernel Alistair Francis
2020-02-24 23:21   ` Alistair Francis
2020-02-25 11:50   ` Laurent Vivier
2020-02-25 11:50     ` Laurent Vivier
2020-02-26 19:32     ` Alistair Francis
2020-02-26 19:32       ` Alistair Francis
2020-02-27  0:02       ` Laurent Vivier
2020-02-27  0:02         ` Laurent Vivier
2020-02-27  0:10         ` Alistair Francis
2020-02-27  0:10           ` Alistair Francis
2020-02-27  0:41           ` Laurent Vivier [this message]
2020-02-27  0:41             ` Laurent Vivier
2020-02-25 13:39 ` [PATCH v2 0/2] linux-user: generate syscall_nr.sh for RISC-V Laurent Vivier
2020-02-25 13:39   ` Laurent Vivier
2020-02-26 19:26   ` Alistair Francis
2020-02-26 19:26     ` Alistair Francis

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=04072aaf-320b-9f23-d3a7-82df223806ba@vivier.eu \
    --to=laurent@vivier.eu \
    --cc=alistair.francis@wdc.com \
    --cc=alistair23@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.