[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1jcoT19D2kSepf8FEwkD5ymnWPm797dHUb+8U_xkMQnA@mail.gmail.com>
Date: Mon, 7 Sep 2020 23:35:45 +0200
From: Arnd Bergmann <arnd@...db.de>
To: musl@...ts.openwall.com
Subject: Re: riscv32 v2
On Mon, Sep 7, 2020 at 8:06 PM Rich Felker <dalias@...c.org> wrote:
> On Mon, Sep 07, 2020 at 06:47:00AM -0400, Stefan O'Rear wrote:
> > * Copy the IPC_TIME64 bits from arch/arm/bits to trigger the musl code
> > for fixing time64 IPC_STAT results. I'm not super happy with this,
> > maybe there should be a new mechanism in musl for fixing IPC_STAT for
> > unconditionally-time64 architectures.
>
> If the riscv32 IPC syscalls don't actually provide in-place time64 but
> require translation, I think it's fairly appropriate as-is.
>
> From the definitions in your patch, it looks like all the time fields
> are fixed-word-order (little endian) and possibly not aligned, so it
> seems like they can't be used in-place. Is this correct?
Yes, rv32 uses the generic system call arguments, which are
unfortunately defined this way. In retrospect I wish I had
replaced the ipc syscalls with a sane version for time64, but at
the time time it seemed as easy way out to use the fields that
had been reserved for this purpose despite the broken
byte order and alignment.
Arnd
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
