Re: [PATCH v2] c-user: Document new clock manager directives
On 17/11/2021 19:32, Sebastian Huber wrote:
On 16/11/2021 22:47, Chris Johns wrote:
On 16/11/21 4:27 am, Sebastian Huber wrote:
On 11/11/2021 08:02, Sebastian Huber wrote:> On 09/11/2021 13:06,
Sebastian
Huber wrote:
On 09/11/2021 08:50, Sebastian Huber wrote:
On 09/11/2021 08:41, Chris Johns wrote:
We could also use something like this:
static inline struct timespec rtems_clock_get_realtime(void)
{
struct timespec time_snapshot;
_Timecounter_Nanotime( &time_snapshot );
return time_snapshot;
}
Unfortunately GCC is not able to optimize this.
Ah OK. This can be fixed and the performance improved but once
the API is
set it
cannot change or do you think we can add a check later and not
break the API?
I filed a GCC bug for this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103150
It seems I was not the only one noticing issues related to
structure returns:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
However, if we want a foolproof API, then I would prefer the
structure
return over the return status and pointer argument. Compilers may
get better
in the future. clang has similar issues, so this is not only a GCC
problem.
We have at least three options for the API:
1. Use the existing FreeBSD implementation as is:
void rtems_clock_get_realtime(struct timespec *);
This is the easiest and most efficient approach.
2. Check for NULL and return a status:
rtems_status_code rtems_clock_get_realtime(struct timespec *);
This requires a wrapper function which is a bit less efficient and
needs more
code/testing:
rtems_status_code
rtems_clock_get_realtime(struct timespec *time_snapshot)
{
if ( time_snapshot == NULL ) {
return RTEMS_INVALID_ADDRESS;
}
_Timecounter_Nanotime( time_snapshot );
return RTEMS_SUCCESSFUL;
}
3. Return the structure and use the existing implementation:
static inline struct timespec rtems_clock_get_realtime(void)
{
struct timespec time_snapshot;
_Timecounter_Nanotime( &time_snapshot );
return time_snapshot;
}
This is currently not well supported by existing compilers:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
4. Do nothing for a NULL pointer:
void rtems_clock_get_realtime(struct timespec *);
This requires a wrapper function which can use a tail call
optimization:
void
rtems_clock_get_realtime(struct timespec *time_snapshot)
{
if ( time_snapshot == NULL ) {
return;
}
_Timecounter_Nanotime( time_snapshot );
}
How do we want to proceed with this? We ship the high performance and
very
useful clock routines from FreeBSD since 2015. I just would like to
add an RTEMS
signature for them and document them in the Clock Manager. Currently,
these
routines are the most efficient way to get clock values in RTEMS.
Developers
afraid of unchecked NULL pointers may use existing RTEMS directives or
clock_get(). It would be nice if we can decide on a way forward.
I will leave this for Joel to decide.
Joel, what is your opinion on this? I accidentally committed this patch:
https://lists.rtems.org/pipermail/devel/2021-November/069984.html
I also checked in the documentation patch. We can adjust the API before
the RTEMS 6 release if necessary.
https://docs.rtems.org/branches/master/c-user/clock/index.html
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
AW: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support
> I am fine with this change being pushed to the 5 branch but I think it needs > to built with the tier 1 archs (i386, powerpc, arm). I could compile them for the BSPs of those archs. Does it make sense to run some test in qemu? > Once pushed I would appreciate an update to: > > https://git.rtems.org/rtems-release/tree/rtems-notes-5.md > > under "## RTEMS 5.2 Release Notes". > > Thanks > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] rtems: Use identifier instead of designator
On 18/11/2021 20:32, Joel Sherrill wrote: On Thu, Nov 18, 2021 at 1:05 PM Sebastian Huber wrote: On 18/11/2021 20:01, Joel Sherrill wrote: OK but do these terms need to be defined somewhere in the RTEMS documentation set? Hm, you mean it could be confusing since we already have "object identifiers". Maybe this was the reason why I used "designator". I guess we should drop this patch. I'm not opposed to it but it is confusing to start with new terminology that isn't defined for us. Maybe we could use "C/C++ declaration identifier" and "C/C++ declaration specifier". -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Testing rtems 7 using rtems-test
Hi Looks like another place that needs version help. rtems-test has a 6 in it somewhere that needs to be overridden. Notice that it is invoking sparc-rtems6-sis when I really want sparc-rtems7-sis. Hopefully there is an existing way to override this easily enough. Otherwise, we are missing a small but essential piece of really testing rtems7. rtems-test --rtems-bsp=leon3-sis `find b-leon3 -name hello.exe` RTEMS Testing - Tester, 6.0.not_released Command Line: /home/joel/rtems-work/tools/7/bin/rtems-test --rtems-bsp=leon3-sis b-leon3/sparc/leon3/testsuites/samples/hello.exe Host: Linux devel.oarcorp.com 3.10.0-1160.41.1.el7.x86_64 #1 SMP Tue Aug 31 14:52:47 UTC 2021 x86_64 Python: 2.7.5 (default, Nov 16 2020, 22:23:17) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] Host: Linux-3.10.0-1160.41.1.el7.x86_64-x86_64-with-centos-7.9.2009-Core (Linux devel.oarcorp.com 3.10.0-1160.41.1.el7.x86_64 #1 SMP Tue Aug 31 14:52:47 UTC 2021 x86_64 x86_64) [1/1] p:0 f:0 u:0 e:0 I:0 B:0 t:0 L:0 i:0 W:0 | sparc/leon3: hello.exe [1/1] p:0 f:0 u:0 e:0 I:0 B:0 t:0 L:0 i:0 W:0 | sparc/leon3: hello.exe Result: invalid Time: 0:00:00.251304 hello.exe => exe: /home/joel/rtems-work/tools/7/bin/sparc-rtems6-sis -leon3 -nouartrx -r -tlim 200 s -m 4 b-leon3/sparc/leon3/testsuites/samples/hello.exe --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Testing rtems 7 using rtems-test
On 20/11/21 5:14 am, Joel Sherrill wrote: > Looks like another place that needs version help. rtems-test has a 6 > in it somewhere that needs to be overridden. It is located here: https://git.rtems.org/rtems-tools/tree/tester/rtems/version.cfg > Notice that it is > invoking sparc-rtems6-sis when I really want sparc-rtems7-sis. > Hopefully there is an existing way to override this easily enough. > Otherwise, we are missing a small but essential piece of really > testing rtems7. Yes it needs to have the `--rtems-version` option added. I will need to play a bit to figure out how to add this. Could you please raise a ticket and assign it to me? Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: AW: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support
On 19/11/21 9:32 pm, gabriel.moy...@dlr.de wrote: >> I am fine with this change being pushed to the 5 branch but I think it needs >> to built with the tier 1 archs (i386, powerpc, arm). > > I could compile them for the BSPs of those archs. Thanks. > Does it make sense to run some test in qemu? Test results are always welcome. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Testing rtems 7 using rtems-test
On Fri, Nov 19, 2021 at 3:45 PM Chris Johns wrote: > > On 20/11/21 5:14 am, Joel Sherrill wrote: > > Looks like another place that needs version help. rtems-test has a 6 > > in it somewhere that needs to be overridden. > > It is located here: > > https://git.rtems.org/rtems-tools/tree/tester/rtems/version.cfg > > > Notice that it is > > invoking sparc-rtems6-sis when I really want sparc-rtems7-sis. > > Hopefully there is an existing way to override this easily enough. > > Otherwise, we are missing a small but essential piece of really > > testing rtems7. > > Yes it needs to have the `--rtems-version` option added. I will need to play a > bit to figure out how to add this. Thanks. We are picking at getting all the test host VMs up and getting baselines for 5, 6, and 7 sweeps. Once we get passable baseline builds, Ryan will post a summary of the more specific failures (like qemu, rtems-mips, etc). On a positive note, the build@ list has had a burst of traffic this week. :) > Could you please raise a ticket and assign it to me? Done. http://devel.rtems.org/ticket/4550 --joel > > Thanks > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
