qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]