From mboxrd@z Thu Jan 1 00:00:00 1970 From: References: <3f76a1b5-24eb-6efb-d8d2-3de10554c7ed@siemens.com> In-Reply-To: <3f76a1b5-24eb-6efb-d8d2-3de10554c7ed@siemens.com> Subject: AW: use of posix function clock_gettime Date: Wed, 10 Jul 2019 22:42:09 +0200 Message-ID: <000101d5375f$f221cd60$d6656820$@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: de List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Jan Kiszka' , xenomai@xenomai.org > First of all, all in-kernel APIs have been deprecated and removed in = favor of RTDM driver APIs. However, RTDM does not expose this clock = directly. You can only do rtdm_clock_read (realtime) or = rtdm_clock_read_monotonic(). This was also my recognising after reading the code and the information = was not really new. Anyway in meantime I have found a workaround/ = solution for our problem. >We could add a host_realtime API to RTDM if there is a good use case. = And that would include a reason why the timestamp adjustment (monotonic = -> host-realtime) cannot be done in the userspace application that = consumes the driver data. >>From my point of view make this always sense if a measurement value = needs an accurate Timestamp by the creating. The other applications = which could need this are fieldbus application.=20 Our measurement system gets her measurement value in the Kernel-Space in = a Xenomia-IRQ and in this case was the old Functionality very smart.=20 A new Functionality RTDM_ host_realtime would be close this gap and = would by also make the RTDM Clock-service completely. Mario HBK