IMO, libcpu/shared is not helpful

Either something is

• cpu-specific, then it should go into cpukit/score/cpu,
• general, then in should go into cpukit/
• bsp-dependent, then it should go into libbsp.

I would strongly suggest to reconsider libcpu/shared.

Moving to 4.11. Needs to be addressed but too much for a branch.

This needs to be part of the source tree rearrangement.

This directory contains only support code for the cache manager. I don't know a better place for these files. They cannot go into cpukit, since the cache manager is potentially BSP-dependent.

Milestone renamed

rtems_shell_main_monitor
is a private function of
cpukit/libmisc/shell/cmds.c

However, the way
testsuites/libtests/monitor02/init.c
uses it (as a public/exported function) to me reads as a strong indication that
rtems_shell_main_monitor()
should be "made public" by declaring/prototyping it in
cpukit/libmisc/shell/shell.h

Exporting this interface from the shell is a hack as well. The central issue is the purpose of the monitor now we have a shell. Should we consume the monitor into the shell and remove the duplicate code in RTEMS ? The monitor has stdin handling, terminal handling plus help formatting (which is much better than the shell's). I think these can all be merged into the shell and the monitor goes away.

I think this should be moved to the 4.11 milestone, which I have done, and we live with the current code for 4.10.

Once issue this raises is the pressure on the shell with all the files that are starting to appear in it. Maybe the monitor command remain in its directory.

The monitor predates the shell. There is really no point in having two CLIs. The monitor commands are available in the shell but the integration is a hack. The monitor commands need to be made first class shell commands and the set for looking at objects enhanced to include more objects.

This may be a decent GSoC project.

Milestone renamed

Fixed in 2011.

This is a part of GSOC2010 project RTEMS Sequenced Initialization. The attachment is the implement of RTEMS Sequenced Initialization API. More details
are placed on the wiki ​http://www.rtems.com/wiki/index.php/RTEMSSequencedInitialization.

This port was done by Marcello Presulli and has been in my inbox for a while. I think I have merged most of their BSP specific work but the lwip has been pending. They managed to run LWIP+SNMP and an application in something like 128K RAM

Here are some email fragments about it.

For now we have just finished to port the latest lwip-1.3.2 based on the latest rtems 4.9.4 version successfully including
a test_app for pings.
We have stressed the stack with ping floods (packetsize 1400 Bytes interval ~150ms) about 250.000 sequences or more without
packet losses and an average latency of 2ms.
Additional we have adopted a new bsp target for the mcf5225x platform.

To lwip now:

we integrated it directly via the autoconfigure/automake process under the
rtems cpukit/liblwip subtree and therefore it gets built with rtems
when u configure it with --enable-networking=lwip appropriately.
The driver on the other side we put it in libcpu/m68k/mcf5225x and it got
built in the library context of the librtemsbsp.a.
The driver has only 2 references on lwip headers ...

To the bsp:

The bsp we have adopted from mcf52223 and have created it as a own
bsp-target=mcf5225x also via the autoconfig/automake mechanism.
In the bsp itself i have modified the bsp_get_CPU_clock_speed() and some
improvements in the console driver and PIT2 timer interrupt.
The bsp_start() we have defined as weak symbol so we don't have to touch
the "empty" bsp_start() of rtems coz it's platform-circuit
specific you know.

This patch is based on a "clean" RTEMS 4.9.4 and offers some modifications/enhancements for the BSP.

• Generic Exception Handler can be used instead of _uhoh

• Flash Driver for the onboard flash including flash security

• DMA initializations can be used to substitute the whole termios, so we saved
  alot of code/memory size

• Bugfixes in fec for the lwip-port, the fec driver works now "optimized" with the lwip-port

• RTC driver routines which configures the RTC clock and time

• generic software trap handler capable of return values

• Bugfix in "old" bsp with MASKALL_BIT when use RTEMS without console

• bugfixes and extensions in bsp header file "mcf5225x.h"

• generic dbg_printk() which prints debug outputs directly via a dma channel

I hope someone have the time to merge it into the CVS head, it shouldn't be
a real task i think.

_ISR_Nest_level should be protected with interrupts disabled in function
_Watchdog_Insert, because another interrupt can occur after _ISR_Nest_level is
saved, causing inconsistency in the global variable.

Yes, by swapping those 2 lines.

Was this fixed?

Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

I am not sure what the problem is. Interrupts are nested, so the code looks all right to me.

For SMP we have to re-write the watchdog stuff anyway and the _Watchdog_Sync_level and _Watchdog_Sync_count will go away.

There is no problem in pre 4.11 versions, since interrupts are nested. Version 4.11 and later use a different watchdog handler implementation.

Milestone renamed

sptests/sp36 is improperly integrated into the rtems buildsystem.

sp36 is missing from SUBDIRS in sptests/Makefile.am, but is referenced in sptests/configure.ac, as well as the code is present in sp36/

sp36/ either should be activated (== added to SUBDIRS) or be fully removed.

sptests/sp36 is improperly integrated into the rtems buildsystem.

sp36 is missing from SUBDIRS in sptests/Makefile.am, but is referenced in sptests/configure.ac, as well as the code is present in sp36/

sp36/ either should be activated (== added to SUBDIRS) or be fully removed.

Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

Milestone renamed

PR1589 commit:
2011-12-08 Joel Sherrill

PR 1589/build

• base_mp/node1/Makefile.am, base_mp/node2/Makefile.am,
  base_sp/Makefile.am, capture/Makefile.am, cdtest/Makefile.am,
  fileio/Makefile.am, hello/Makefile.am, iostream/Makefile.am,
  loopback/Makefile.am, minimum/Makefile.am, nsecs/Makefile.am,
  paranoia/Makefile.am, pppd/Makefile.am, ticker/Makefile.am,
  unlimited/Makefile.am: Remove obsolete optional manager capability.

and
2011-12-08 Joel Sherrill

PR 1589/build

• mp01/node1/Makefile.am, mp01/node2/Makefile.am,
  mp02/node1/Makefile.am, mp02/node2/Makefile.am,
  mp03/node1/Makefile.am, mp03/node2/Makefile.am,
  mp04/node1/Makefile.am, mp04/node2/Makefile.am,
  mp05/node1/Makefile.am, mp05/node2/Makefile.am,
  mp06/node1/Makefile.am, mp06/node2/Makefile.am,
  mp07/node1/Makefile.am, mp07/node2/Makefile.am,
  mp08/node1/Makefile.am, mp08/node2/Makefile.am,
  mp09/node1/Makefile.am, mp09/node2/Makefile.am,
  mp10/node1/Makefile.am, mp10/node2/Makefile.am,
  mp11/node1/Makefile.am, mp11/node2/Makefile.am,
  mp12/node1/Makefile.am, mp12/node2/Makefile.am,
  mp13/node1/Makefile.am, mp13/node2/Makefile.am,
  mp14/node1/Makefile.am, mp14/node2/Makefile.am: Remove obsolete
  optional manager capability.

remove LINK_OBJS from the MP tests. They do no compile anymore. This patch re-adds them.

Would it be proper to change the suffix of the input in default-bsp-post-link in rtems/make/leaf.cfg ?

Namely changing:

define default-bsp-post-link

• $(NM) -g -n $@ > $(basename $@).num
• $(SIZE) $@

endef

define default-bsp-post-link
+ $(NM) -g -n $@.o > $(basename $@).num
+ $(SIZE) $@.o
endef

I'm working on the application side of RTEMS (as opposed to the source), but here are the errors I encountered, what I did to find the problem, and the results.

I kept getting errors when I ran the BuildTests?.sh...

~/rtems-addon-packages/examples/openldap$
...
i386-rtems4.11-nm o-optimize/slapd-addel
i386-rtems4.11-nm: 'o-optimize/slapd-addel': No such file
...
~/rtems-addon-packages/examples/openldap$
...
i386-rtems4.11-size o-optimize/slapd-addel
i386-rtems4.11-size: 'o-optimize/slapd-addel': No such file

After looking at the Makefile it looks like they were called by: “make-exe”.

Doing

grep -r “make-exe” /opt

revealed “make-exe” is defined in /opt/rtems-4.11/make/leaf.cfg, which calls bsp-post-link, (which is exactly the stage of the build process giving errors).

According to man, nm and size work on object files. So, I changed the suffixes in /opt/rtems-4.11/make/leaf.cfg and the errors went away. After making the change, the following additional objects appeared in o-optimize:

*.bin and *.ralf, with an approximate size of 570,000. The sizes vary slightly...

If changing the suffixes in /opt/rtems-4.11/make/leaf.cfg makes sense, would it make sense to change them for rtems/make/leaf.cfg ? Also, there are other target.cfg's in the different bsp s that may have similar problems.

Thanks,
Cynthia Rempel

Would it be proper to change the suffix of the input in default-bsp-post-link in rtems/make/leaf.cfg ?

Namely changing:

define default-bsp-post-link

endef

define default-bsp-post-link + $(NM) -g -n $@.o > $(basename $@).num + $(SIZE) $@.o endef

I'm working on the application side of RTEMS (as opposed to the source), but here are the errors I encountered, what I did to find the problem, and the results.

I kept getting errors when I ran the BuildTests?.sh...

~/rtems-addon-packages/examples/openldap$ ... i386-rtems4.11-nm o-optimize/slapd-addel i386-rtems4.11-nm: 'o-optimize/slapd-addel': No such file ... ~/rtems-addon-packages/examples/openldap$ ... i386-rtems4.11-size o-optimize/slapd-addel i386-rtems4.11-size: 'o-optimize/slapd-addel': No such file

After looking at the Makefile it looks like they were called by: “make-exe”.

Doing

grep -r “make-exe” /opt

revealed “make-exe” is defined in /opt/rtems-4.11/make/leaf.cfg, which calls bsp-post-link, (which is exactly the stage of the build process giving errors).

According to man, nm and size work on object files. So, I changed the suffixes in /opt/rtems-4.11/make/leaf.cfg and the errors went away. After making the change, the following additional objects appeared in o-optimize:

*.bin and *.ralf, with an approximate size of 570,000. The sizes vary slightly...

If changing the suffixes in /opt/rtems-4.11/make/leaf.cfg makes sense, would it make sense to change them for rtems/make/leaf.cfg ? Also, there are other target.cfg's in the different bsp s that may have similar problems.

Thanks, Cynthia Rempel

Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

Milestone renamed

The avr io.h header gives a warning that if not doing avr-libc, that if not heeded leads to many errors.

Need an avr-libc configuration file... should be a place-holding stub that states this is a problematic build.

Anyway, these are just some cans of worms... FYI

AVR has issues so deep it requires ~50 patches for binutils, ~60 patches for gcc, and has ~14 patches for avr-libc.

I suspect getting ONE functional AVR-RTEMS a major undertaking... I wonder if it might be worth exploring using ATMEL's prepatched toolchain for non-Ada builds... For Ada-builds, that's going to be another major undertaking...

Eric Weddington (at ATMEL) is recommending the use of their source for C, C++ builds... ​http://distribute.atmel.no/tools/opensource/Atmel-AVR-Toolchain-3.4.1/avr/

Although the Rolf Ebert (at AVR-Ada) have their own patch-set (using different tool versions) etc, which is making updating the AVR port so challenging... ​http://sourceforge.net/projects/avr-ada/files/avr-ada/Source%20Dist/

Their source-builder is located at:
avr-ada/tools/build/build-avr-ada.sh

Replying to comment:14:

... gcc won't build without a libc... (complains about 'limits.h') gcc-4.8.0 has an internal compiler error with avr-libc, and newlib is too big for AVR, so going back to gcc-4.7.2 with avr-libc... avr community maintains non-rtems targets, so using an avr target (as opposed to avr-rtems4.11)

This is OK. The avr GCC community needs to know this so they can decide what to do. Unfortunately as much as we would like all targets to upgrade in lockstep, it doesn't happen. We would need a more aggressive testing program to know this as early as possible and attempt to fix an issue. And we could still end up in this situation.

Milestone renamed

I need statvfs for MS-DOS filesystem in my project. Share implementation and example shell command 'df' - like in GNU coreutils, but very simplified.

It is not clear which date and time is returned by rtems_clock_get_tod(). For example which time zone is used. Is there a relation to UTC?

The timezone is the one you used when you set the time with the set call. If the time is not set this function returns RTEMS_NOT_DEFINED. It is assumed you set a suitable time in the first place and know the specific context of use.

Bump priority to highest for tickets with a fix attached or seemingly simple fix proposed in the description or comments.

bump milestone

This ticket does not have a patch attached or an obvious (to me) fix. What is the fix proposed?

We need a more precise documentation of the time services. How are leap seconds handled for example? UNIX time vs. UTC.

The wall clock time services lack documentation in general. What is the relation between rtems_time_of_day and the UNIX time as specified by IEEE Std 1003.1, 2013 Edition, 4.15 Seconds Since the Epoch (​http://pubs.opengroup.org/onlinepubs/9699919799/). For example _TOD_To_seconds() does not use the expression in this standard document. This affects rtems_timer_fire_when().

Can you provide a specific link? That is to the top of the standard.

4.15 Seconds Since the Epoch

​http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html

See also

​http://www.madore.org/~david/computers/unix-leap-seconds.html

Documentation was improved for RTEMS 6.

We have similar code in rtems_tarfs_load(), Untar_FromMemory() and Untar_FromFile(). These functions should instead use a common TAR archive iterator with specific visitor functions.

Duplicate of #2415.

Milestone renamed

The x86 context switch code does not implement the "is executing" hand-off protocol used on the other ports. It should.

​https://devel.rtems.org/ticket/2183

How can we set the duplicate like on Bugzilla?

Milestone renamed

The nios2 soft-core processor is probably a bit of a different beast because it has many options when the FPGA programming is configured. It is probably therefore not a good context for the use of multilibs, although it is possible to enable them.

For the nios2 RTEMS automated system configuration I must interrogate the Altera sopcinfo file to properly specify some of the nios2 cpu instance specific compiler flags such as {-mhw-div, -mhw-mul, -mhw-mulx}.

An easy way to do this is to build some custom tools that need to run _only_on_the_host_ during the build. The source code for these BSP instance custom tools are easy to write if they include header files from the Altera generated HAL {system.h, linker.h}, when they are built. The Altera HAL needs to also be generated, but not installed, during the gnu build. It seems that this is the way that Altera intends for users to learn about system configuration based on how often their file formats evolve, and also based on lack of documentation for their sopcinfo file. Nevertheless, for many reasons we don't include Altera generated header files into any RTEMS BSP or cpukit source code.

Currently this approach is difficult to fully implement because I must finish the interrogation for the CPU flags during the gnu build system configure phase when CFLAGS_OPTIMIZE_V and CPU_FLAGS are fetched from the custom .cfg file, and so I am unable to build some custom tools that need to run _only_on_the_host_ during the build at that time.

However, during the preinstall phase it is easy to create a custom "bsp_specs_cpu" file like this.

*[cpuspecs]:
*[cpuspecs]: %(cpuspecs) -mhw-div
*[cpuspecs]: %(cpuspecs) -mhw-mul
*[cpuspecs]: %(cpuspecs) -mhw-mulx

Which could be used in "bsp_specs" like this.

%rename cc1 old_cc1
%rename cc1plus old_cc1plus
%rename lib old_lib
%rename endfile old_endfile
%rename startfile old_startfile
%rename link old_link

%include

*cc1:
%{!qrtems: %{old_cc1} } \
%{qrtems*: %{old_cc1} %{cpuspecs} }

*cc1plus:
%{!qrtems: %{old_cc1plus} } \
%{qrtems*: %{old_cc1plus} %{cpuspecs} }

*lib:
%{!qrtems: %(old_lib)} \
%{!nostdlib: %{qrtems: --start-group -lrtemsbsp -lrtemscpu -lc -lgcc --end-group \
%{!qnolinkcmds: -T linkcmds%s`

*startfile:
%{!qrtems: %(old_startfile)} \
%{!nostdlib: %{qrtems: start0.o%s start1.o%s crti.o%s \

crtbegin.o%s -e start -u exception_vector }}

*link:
%{!qrtems: %(old_link)} %{qrtems: -dc -dp -N}

*endfile:
%{!qrtems: %(old_endfile)} %{qrtems: crtend.o%s crtn.o%s}

This works very nicely excepting that the cpukit isn't built specifying a spec file and so it could use the wrong instructions when generating code. Therefore its tempting to modify the RTEMS build like this.

cpukit/aclocal/gcc-specs.m4 | 20 ++++++++++++++++++++
cpukit/aclocal/prog-cc.m4 | 8 ++++++++
cpukit/automake/compile.am | 5 +++++
3 files changed, 33 insertions(+)

diff --git a/cpukit/aclocal/gcc-specs.m4 b/cpukit/aclocal/gcc-specs.m4
new file mode 100644
index 0000000..dd49bb9
--- /dev/null
+++ b/cpukit/aclocal/gcc-specs.m4
@@ -0,0 +1,20 @@
+dnl
+dnl $Id$
+dnl
+dnl Check whether the target compiler accepts -specs
+dnl
+
+AC_DEFUN([RTEMS_GCC_SPECS],
+[AC_REQUIRE([RTEMS_PROG_CC])
+AC_CACHE_CHECK(whether $CC accepts -specs,rtems_cv_gcc_specs,
+[
+rtems_cv_gcc_specs=no
+if test x"$GCC" = x"yes"; then
+ touch confspec
+ echo 'void f(){}' >conftest.c
+ if test -z "${CC} -specs confspec -c conftest.c 2>&1";then
+ rtems_cv_gcc_specs=yes
+ fi
+fi
+rm -f confspec conftest*
+])])
diff --git a/cpukit/aclocal/prog-cc.m4 b/cpukit/aclocal/prog-cc.m4
index e8b27b5..8dae5de 100644
--- a/cpukit/aclocal/prog-cc.m4
+++ b/cpukit/aclocal/prog-cc.m4
@@ -27,6 +27,14 @@ dnl check if the target compiler may use --pipe

RTEMS_GCC_PIPE
test "$rtems_cv_gcc_pipe" = "yes" && CC="$CC --pipe"

+dnl check if the compiler supports --specs
+RTEMS_GCC_SPECS
+
+AS_IF([test x"$rtems_cv_gcc_specs" = xyes],[
+GCCSPECS="-B\$(PROJECT_ROOT)/lib/ -B\$(PROJECT_ROOT)/$RTEMS_BSP/lib/"
+GCCSPECS="${GCCSPECS} -specs bsp_specs -qrtems_cpukit"])
+AC_SUBST(GCCSPECS)
+

# Append warning flags if CFLAGS wasn't set.
AS_IF([test "$GCC" = yes && test "$rtems_cv_CFLAGS_set" != set],
[CFLAGS="$CFLAGS -Wall"])

diff --git a/cpukit/automake/compile.am b/cpukit/automake/compile.am
index 3d81426..0e43494 100644
--- a/cpukit/automake/compile.am
+++ b/cpukit/automake/compile.am
@@ -2,6 +2,11 @@

## $Id$
##

+CC = @CC@ $(GCCSPECS)
+CXX = @CXX@ $(GCCSPECS)
+CPP = @CPP@ $(GCCSPECS)
+CCAS = @CCAS@ $(GCCSPECS)
+

AM_CPPFLAGS = @RTEMS_CPPFLAGS@
AM_CFLAGS =
AM_CCASFLAGS = @RTEMS_CCASFLAGS@

I am thinking that hopefully this wont break any existing CPU architecture and or BSP because of several reasons.

1) Perhaps typical BSPs included in RTEMS are only modifying the way that executables are linked, and we probably don't create executables during the cpukit build.

2) Probably most of the spec files are noop implementation if qrtems isnt specified, and for the cpu kit I specify -qrtems_cpukit

3) I am specifying -qrtems_cpukit so its easy to write a spec file that does different things when it is and isnt a cpukit build. We could I suppose also define -qrtems_cpukit_multilib in that specific situation, if it were important to break that situation out.

In any case this is what I currently have implemented and I will need to look for plan B before I can merge my nios2 support if this type of change looks like a bad idea.

I am therefore writing to the relevant RTEMS wizards for some guidance.

Thanks for your consideration.

BSP variants may be added in the new build system for each multilib.

nios2-rtems4.11-g++ -B../../../../../nios2_iss/lib/ -specs bsp_specs -qrtems -mno-hw-mul -mno-hw-div -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -mno-hw-mul -mno-hw-div -o cxx_iostream.exe init.o
/users/joel/rtems-4.11-work/tools/lib/gcc/nios2-rtems4.11/4.9.2/libstdc++.a(ios-inst.o): In function `atomic_add':
/users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/nios2-rtems4.11-gcc-4.9.2-newlib-2.2.0.20150323-x86_64-linux-gnu-1/build/nios2-rtems4.11/libstdc++-v3/include/ext/atomicity.h:53: undefined reference to `sync_fetch_and_add_4'
/users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/nios2-rtems4.11-gcc-4.9.2-newlib-2.2.0.20150323-x86_64-linux-gnu-1/build/nios2-rtems4.11/libstdc++-v3/include/ext/atomicity.h:53: undefined reference to `sync_fetch_and_add_4'
/users/joel/rtems-4.11-work/tools/lib/gcc/nios2-rtems4.11/4.9.2/libstdc++.a(ios_init.o): In function `exchange_and_add_dispatch':
/users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/nios2-rtems4.11-gcc-4.9.2-newlib-2.2.0.20150323-x86_64-linux-gnu-1/build/nios2-rtems4.11/libstdc++-v3/include/ext/atomicity.h:49: undefined reference to `sync_fetch_and_add_4'
/users/joel/rtems-4.11-work/tools/lib/gcc/nios2-rtems4.11/4.9.2/libstdc++.a(ios_init.o): In function `atomic_add_dispatch':
/users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/nios2-rtems4.11-gcc-4.9.2-newlib-2.2.0.20150323-x86_64-linux-gnu-1/build/nios2-rtems4.11/libstdc++-v3/include/ext/atomicity.h:53: undefined reference to `sync_fetch_and_add_4'
/users/joel/rtems-4.11-work/tools/lib/gcc/nios2-rtems4.11/4.9.2/libstdc++.a(ios_init.o): In function `exchange_and_add_dispatch':
/users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/nios2-rtems4.11-gcc-4.9.2-newlib-2.2.0.20150323-x86_64-linux-gnu-1/build/nios2-rtems4.11/libstdc++-v3/include/ext/atomicity.h:49: undefined reference to `sync_fetch_and_add_4'
/users/joel/rtems-4.11-work/tools/lib/gcc/nios2-rtems4.11/4.9.2/libstdc++.a(locale-inst.o):/users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/nios2-rtems4.11-gcc-4.9.2-newlib-2.2.0.20150323-x86_64-linux-gnu-1/build/nios2-rtems4.11/libstdc++-v3/include/ext/atomicity.h:49: more undefined references to `sync_fetch_and_add_4' follow

Still happens on

nios2-rtems4.12-gcc (GCC) 6.2.1 20161110 (RTEMS 4.12, RSB 5469a486e1b67532e20c48e154c7263c59047be4, Newlib 2.4.0.20161025)

This is the only target left with this issue. Help would be appreciated in resolving this.

From my point of view this is a GCC bug:

​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357

Problem fixed in GCC 7. I wait for a back port to GCC 6.

The FreeBSD timecounter implementation supports the NTP. This support is currently disabled in RTEMS.

There needs to be an interface in the score to provide access to ntp_update_second(). The call may not be present in the kernel sources, it will mostly likely be provided by an application or an external library such as libbsd.a.

I suggest a file is added to the score that contains ntp_update_second() and that function checks a function pointer and if set the function is called. This brings kern_tc.c closer to upstream FreeBSD sources.

While on the topic of kern_tc.c and being as close to FB as we can, I think the RTEMS doxygen comments should be removed. We should maintain a common policy for imported sources like this.

Good timing, I recently updated kern_tc.c to the latest FreeBSD version:

​https://git.rtems.org/sebh/rtems.git/log/?h=timecounter-2021

I just didn't send the patch set for review yet, since nobody commented on the new clock manager directives so far:

​https://lists.rtems.org/pipermail/devel/2021-October/069697.html

The kern_tc.c is quite close to the original FreeBSD code and the Doxygen comment block on top of the file is not an issue.

In this patch set I removed the NTP code block since nobody was interested in NTP support in the last 6 years:

​https://git.rtems.org/sebh/rtems.git/commit/?h=timecounter-2021&id=f85259b1edfff1d89c013c97510a9427825ea81b

This enabled a performance optimization here:

​https://git.rtems.org/sebh/rtems.git/commit/?h=timecounter-2021&id=04ed8d3c8cf88b7f1e3fb7ad78a91be1fefc396c

The performance optimization is important for targets with slow 64-bit divisions (which are most RTEMS targets). If you want to add NTP support, then we have to restructure the FreeBSD code a bit. This can be integrated in FreeBSD. I can do this it just depends on how urgent it is.

In a first approach the proposed callback makes sense. If someone using lwIP needs NTP support, then we can add kern_ntptime.c to RTEMS.

Replying to Sebastian Huber:

Good timing, I recently updated kern_tc.c to the latest FreeBSD version:

It does seem so. :)

​https://git.rtems.org/sebh/rtems.git/log/?h=timecounter-2021

I just didn't send the patch set for review yet, since nobody commented on the new clock manager directives so far:

I only suspected something was in the works because of the posts to FreeBSD hackers. It would be good to resolve the PTP support.

​https://lists.rtems.org/pipermail/devel/2021-October/069697.html

I saw this but I did not look closely. I did not know it was a request for a new feature. I will add it to my list so sorry about that.

The kern_tc.c is quite close to the original FreeBSD code and the Doxygen comment block on top of the file is not an issue.

Why the special exception here?

My focus for the leadership group, including you, is to set policies for this sort of thing and then having everyone accept and adhere to them. It is simpler and more democratic to do this. My concern is having a rule that creates an exceptions because it makes things complicated. I know this is a single file but there are other places where more code comes across and this is where things become confusing.

In this patch set I removed the NTP code block since nobody was interested in NTP support in the last 6 years:

​https://git.rtems.org/sebh/rtems.git/commit/?h=timecounter-2021&id=f85259b1edfff1d89c013c97510a9427825ea81b

It is needed. I have openly discuss this topic ...

​https://lists.rtems.org/pipermail/devel/2021-March/065608.html

The PTP changes for RTEMS have only just been posted upstream ..

​https://github.com/ptpd/ptpd/pull/85

Gabriel has done a fantastic job getting my hacks into a suitable state they would be pushed upstream.

This enabled a performance optimization here:

​https://git.rtems.org/sebh/rtems.git/commit/?h=timecounter-2021&id=04ed8d3c8cf88b7f1e3fb7ad78a91be1fefc396c

The performance optimization is important for targets with slow 64-bit divisions (which are most RTEMS targets). If you want to add NTP support, then we have to restructure the FreeBSD code a bit. This can be integrated in FreeBSD. I can do this it just depends on how urgent it is.

I have nothing to offer here and will happily be guided by you. I am sorry I have no time to spend looking at the detail.

In a first approach the proposed callback makes sense. If someone using lwIP needs NTP support, then we can add kern_ntptime.c to RTEMS.

The support being added is LibBSD so I am not sure where kern_ntptime.c is being added. Maybe Gabriel can be comment more on this.

kern_ntptime.c is ported from freebsd-org to freebsd in rtems-libbsd. The last commits of this branch ​https://github.com/GabrielDai/rtems-libbsd/tree/ptpd show the changes.

Regarding adding the function ntp_update_second() in score, do you know where the function pointer should be updated (to point to ntp_update_second() in kern_ntptime.c)?

Replying to Chris Johns:

Replying to Sebastian Huber:

The kern_tc.c is quite close to the original FreeBSD code and the Doxygen comment block on top of the file is not an issue.

Why the special exception here?

My focus for the leadership group, including you, is to set policies for this sort of thing and then having everyone accept and adhere to them. It is simpler and more democratic to do this. My concern is having a rule that creates an exceptions because it makes things complicated. I know this is a single file but there are other places where more code comes across and this is where things become confusing.

There is not just one rule involved here. The timekeeping is an important service of an operating system. It should be visible in the internal documentation (Doxygen). The file history shows that there is no issue with keeping it in synchronization with FreeBSD.

Replying to GabrielMoyano:

kern_ntptime.c is ported from freebsd-org to freebsd in rtems-libbsd. The last commits of this branch ​https://github.com/GabrielDai/rtems-libbsd/tree/ptpd show the changes.

Regarding adding the function ntp_update_second() in score, do you know where the function pointer should be updated (to point to ntp_update_second() in kern_ntptime.c)?

The callback for ntp_update_second() is currently not implemented. I would like to integrate my patch set which updates kern_tc.c to the latest FreeBSD version first. I would like to also try to rearrange the code a bit in the FreeBSD upstream. For libbsd my approach would be to add an internal API to #include which can be used to set the NTP callback in kern_ntptime.c.

Replying to Sebastian Huber:

Replying to Chris Johns:

Replying to Sebastian Huber:

The kern_tc.c is quite close to the original FreeBSD code and the Doxygen comment block on top of the file is not an issue.

Why the special exception here?

My focus for the leadership group, including you, is to set policies for this sort of thing and then having everyone accept and adhere to them. It is simpler and more democratic to do this. My concern is having a rule that creates an exceptions because it makes things complicated. I know this is a single file but there are other places where more code comes across and this is where things become confusing.

There is not just one rule involved here. The timekeeping is an important service of an operating system. It should be visible in the internal documentation (Doxygen). The file history shows that there is no issue with keeping it in synchronization with FreeBSD.

This is not about the history. The history of this file reflects the quality of the person currently doing the work and it is a very high standard. Expecting that standard everywhere is asking a lot. I think we need to document how we integrate external code and for that I was considering the following as the basis:

​https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md#n248

I would be interested to understand how this score file or files like it could be handled by a rule or rules? A rule in the ticket may not be clean and suitable documentation however it provides me with a means to show what we consider as OK if you could provide this.

Replying to Chris Johns:

Replying to Sebastian Huber:

Replying to Chris Johns:

Replying to Sebastian Huber:

The kern_tc.c is quite close to the original FreeBSD code and the Doxygen comment block on top of the file is not an issue.

Why the special exception here?

My focus for the leadership group, including you, is to set policies for this sort of thing and then having everyone accept and adhere to them. It is simpler and more democratic to do this. My concern is having a rule that creates an exceptions because it makes things complicated. I know this is a single file but there are other places where more code comes across and this is where things become confusing.

There is not just one rule involved here. The timekeeping is an important service of an operating system. It should be visible in the internal documentation (Doxygen). The file history shows that there is no issue with keeping it in synchronization with FreeBSD.

This is not about the history. The history of this file reflects the quality of the person currently doing the work and it is a very high standard. Expecting that standard everywhere is asking a lot. I think we need to document how we integrate external code and for that I was considering the following as the basis:

​https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md#n248

I would be interested to understand how this score file or files like it could be handled by a rule or rules? A rule in the ticket may not be clean and suitable documentation however it provides me with a means to show what we consider as OK if you could provide this.

The libbsd contributing rules make sense for libbsd which deals with a couple of hundred files and a semi-automatic synchronization support.

External files placed in the score should integrate into the score documentation and be maintainable. Here we need a bit more flexibility.

I updated the timecounter update branch to include support for an NTP update second handler:

​https://git.rtems.org/sebh/rtems.git/log/?h=timecounter-2021

​https://git.rtems.org/sebh/rtems.git/commit/?h=timecounter-2021&id=817437b6dda00764f368b2da9eeab67ec284a3bd

I wait for some feedback on the FreeBSD mailing list before I send the patch set for review.

Replying to Sebastian Huber:

I updated the timecounter update branch to include support for an NTP update second handler:

​https://git.rtems.org/sebh/rtems.git/log/?h=timecounter-2021

​https://git.rtems.org/sebh/rtems.git/commit/?h=timecounter-2021&id=817437b6dda00764f368b2da9eeab67ec284a3bd

This looks nice, thx. Now, I guess that one option is to call _Timecounter_Set_NTP_update_second() just before starting ptpd

I wait for some feedback on the FreeBSD mailing list before I send the patch set for review.

ok

Replying to Sebastian Huber:

Replying to Chris Johns:

Replying to Sebastian Huber:

Replying to Chris Johns:

Replying to Sebastian Huber:

The kern_tc.c is quite close to the original FreeBSD code and the Doxygen comment block on top of the file is not an issue.

Why the special exception here?

My focus for the leadership group, including you, is to set policies for this sort of thing and then having everyone accept and adhere to them. It is simpler and more democratic to do this. My concern is having a rule that creates an exceptions because it makes things complicated. I know this is a single file but there are other places where more code comes across and this is where things become confusing.

There is not just one rule involved here. The timekeeping is an important service of an operating system. It should be visible in the internal documentation (Doxygen). The file history shows that there is no issue with keeping it in synchronization with FreeBSD.

This is not about the history. The history of this file reflects the quality of the person currently doing the work and it is a very high standard. Expecting that standard everywhere is asking a lot. I think we need to document how we integrate external code and for that I was considering the following as the basis:

​https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md#n248

I would be interested to understand how this score file or files like it could be handled by a rule or rules? A rule in the ticket may not be clean and suitable documentation however it provides me with a means to show what we consider as OK if you could provide this.

The libbsd contributing rules make sense for libbsd which deals with a couple of hundred files and a semi-automatic synchronization support.

External files placed in the score should integrate into the score documentation and be maintainable. Here we need a bit more flexibility.

This makes sense. Should the documentation should be limited to a single block at the start of the file and else where in the file the LibBSD rules apply?

In ffb8833d/rtems:

Replying to GabrielMoyano:

Replying to Sebastian Huber:

I updated the timecounter update branch to include support for an NTP update second handler:

​https://git.rtems.org/sebh/rtems.git/log/?h=timecounter-2021

​https://git.rtems.org/sebh/rtems.git/commit/?h=timecounter-2021&id=817437b6dda00764f368b2da9eeab67ec284a3bd

This looks nice, thx. Now, I guess that one option is to call _Timecounter_Set_NTP_update_second() just before starting ptpd

I wait for some feedback on the FreeBSD mailing list before I send the patch set for review.

ok

I checked in the patch set. The kern_tc.c is now fully synchronized with the latest FreeBSD version. You can now install an NTP update second handler via _Timecounter_Set_NTP_update_second() from #include .

I checked in the patch set. The kern_tc.c is now fully synchronized with the latest FreeBSD version. You can now install an NTP update second handler via _Timecounter_Set_NTP_update_second() from #include .

Thank you very much Sebastian. Are the changes portable to the branch 5? Our development is based on that branch and it will be very nice to have them there too

Replying to GabrielMoyano:

I checked in the patch set. The kern_tc.c is now fully synchronized with the latest FreeBSD version. You can now install an NTP update second handler via _Timecounter_Set_NTP_update_second() from #include .

Thank you very much Sebastian. Are the changes portable to the branch 5? Our development is based on that branch and it will be very nice to have them there too

I think the patch set is back portable to RTEMS 5 without breaking the ABI/API. Just clone this ticket and set the mile stone to 5.2. Then try to back port all the changes or a subset and send it for review. I have no time to work on it.

I think the patch set is back portable to RTEMS 5 without breaking the ABI/API. Just clone this ticket and set the mile stone to 5.2. Then try to back port all the changes or a subset and send it for review. I have no time to work on it.

Thx. I'll do so. Here the ticket ​https://devel.rtems.org/ticket/4549#ticket

Is this ticket ready to close?

In 91057b3/rtems:

In 8f1e8f8f/rtems:

The FreeBSD timecounter implementation supports the RFC 2783 PPS-API. This support is currently disabled in RTEMS.

In 9b4212c7/rtems:

In a3930e8c/rtems:

In bf61753a/rtems:

In 95c747d9/rtems:

In ac4ea53/rtems:

In c34d3ae/rtems:

In 13513b81/rtems:

In b304603b/rtems:

In b3e4f58/rtems:

In 5ccf960/rtems:

In 6553bf4/rtems:

In 495f836/rtems:

In 044e8b6/rtems:

In 34ba0e5a/rtems:

In 11621c9c/rtems:

In 94df3a7a/rtems:

In eefaf068/rtems:

In 013e028/rtems: