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.