[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v8 1/2] linux-user: Add support for clock_adjtim
From: |
Aleksandar Markovic |
Subject: |
Re: [Qemu-devel] [PATCH v8 1/2] linux-user: Add support for clock_adjtime() syscall |
Date: |
Mon, 10 Oct 2016 10:34:26 +0000 |
Hi,
Thanks for bringing up this issue. LTP was not the reference for this
implementation. Man page does not exist. The reference was kernel source. Apart
from source code analysis. test examples were utilized to confirm the same
behavior on real and emulated systems.
Yours,
Aleksandar
________________________________________
From: Peter Maydell address@hidden
Sent: Monday, October 10, 2016 3:25 AM
To: Aleksandar Markovic
Cc: QEMU Developers; Riku Voipio; Laurent Vivier; Petar Jovanovic; Miodrag
Dinic; Aleksandar Rikalo; Aleksandar Markovic
Subject: Re: [PATCH v8 1/2] linux-user: Add support for clock_adjtime() syscall
On 10 October 2016 at 11:18, Aleksandar Markovic
<address@hidden> wrote:
> From: Aleksandar Markovic <address@hidden>
>
> This patch implements Qemu user mode clock_adjtime() syscall support.
>
> The implementation is based on invocation of host's clock_adjtime().
> There are fairly complex rules regarding conditions for each error
> code that could be returned by clock_adjtime(). They are all taken
> into account while conversions of pointers to timex structure between
> target and host are done. By passing NULL as the second argument
> in certain cases, it is assured that the emulated clock_adjtime()
> will return the correct error code for all cases of its input.
Is this ordering of which error conditions are checked first
actually mandated by the clock_adjtime() documentation, or is
this just placating an LTP test case that does two wrong things
at once when it's really only trying to test one of them?
If the latter, I think it's better to fix the broken LTP test
case. (For instance
https://github.com/linux-test-project/ltp/commit/3d4b0e9aa524fc6418d34614299ac2df1e8045ae
is a fix for an issue like that in handling the read syscall.)
thanks
-- PMM