[PATCH v2] shell: Fix warning visible with latest Newlib
Works also with previous Newlib versions. --- cpukit/libmisc/shell/main_date.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cpukit/libmisc/shell/main_date.c b/cpukit/libmisc/shell/main_date.c index 9b970a6..6070ff0 100644 --- a/cpukit/libmisc/shell/main_date.c +++ b/cpukit/libmisc/shell/main_date.c @@ -16,10 +16,12 @@ #include "config.h" #endif +#define _GNU_SOURCE #include #include #include #include +#include #include #include -- 1.8.4.5 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 02/12] score: Add ticks per second to configuration
On 8/04/2016 4:49 PM, Sebastian Huber wrote: This avoids the calculation of this value at run-time, similar to rtems_configuration_get_nanoseconds_per_tick(). Delete TOD_TICKS_PER_SECOND and replace it with rtems_configuration_get_ticks_per_second(). --- a/cpukit/sapi/include/confdefs.h +++ b/cpukit/sapi/include/confdefs.h @@ -3413,6 +3413,7 @@ extern rtems_initialization_tasks_table Initialization_tasks[]; CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS, /* enabled */ CONFIGURE_MICROSECONDS_PER_TICK, /* microseconds per clock tick */ 1000 * CONFIGURE_MICROSECONDS_PER_TICK, /* nanoseconds per clock tick */ +100 / CONFIGURE_MICROSECONDS_PER_TICK,/* ticks per second */ CONFIGURE_TICKS_PER_TIMESLICE,/* ticks per timeslice quantum */ CONFIGURE_IDLE_TASK_BODY, /* user's IDLE task */ CONFIGURE_IDLE_TASK_STACK_SIZE, /* IDLE task stack size */ I assume the microsecond, nanosecond and tick per sec values all need to agree. Does anything check this is the case and raise a fatal error if they do not? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 02/12] score: Add ticks per second to configuration
On 08/04/16 09:06, Chris Johns wrote: On 8/04/2016 4:49 PM, Sebastian Huber wrote: This avoids the calculation of this value at run-time, similar to rtems_configuration_get_nanoseconds_per_tick(). Delete TOD_TICKS_PER_SECOND and replace it with rtems_configuration_get_ticks_per_second(). --- a/cpukit/sapi/include/confdefs.h +++ b/cpukit/sapi/include/confdefs.h @@ -3413,6 +3413,7 @@ extern rtems_initialization_tasks_table Initialization_tasks[]; CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS, /* enabled */ CONFIGURE_MICROSECONDS_PER_TICK, /* microseconds per clock tick */ 1000 * CONFIGURE_MICROSECONDS_PER_TICK, /* nanoseconds per clock tick */ +100 / CONFIGURE_MICROSECONDS_PER_TICK,/* ticks per second */ CONFIGURE_TICKS_PER_TIMESLICE,/* ticks per timeslice quantum */ CONFIGURE_IDLE_TASK_BODY, /* user's IDLE task */ CONFIGURE_IDLE_TASK_STACK_SIZE, /* IDLE task stack size */ I assume the microsecond, nanosecond and tick per sec values all need to agree. Does anything check this is the case and raise a fatal error if they do not? Currently nobody checks this. Should we check this via an _Assert()? If we add new fatal errors, it will get difficult. We need to test it. The Configuration is read-only. We would have to avoid to create a corrupt Configuration and this is very bad. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 02/12] score: Add ticks per second to configuration
On 8/04/2016 5:35 PM, Sebastian Huber wrote: On 08/04/16 09:06, Chris Johns wrote: I assume the microsecond, nanosecond and tick per sec values all need to agree. Does anything check this is the case and raise a fatal error if they do not? Currently nobody checks this. Should we check this via an _Assert()? If we add new fatal errors, it will get difficult. We need to test it. Yes an assert is perfect. It is a hard config error. The Configuration is read-only. We would have to avoid to create a corrupt Configuration and this is very bad. It is not recommended anyone manually create their own Configuration table but there is nothing that says you _have_ to use confdefs.h. I do remember the pre-confdefs days. If we create a dependence we should ensure things are within spec before continuing. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 02/12] score: Add ticks per second to configuration
On 08/04/16 10:07, Chris Johns wrote: On 8/04/2016 5:35 PM, Sebastian Huber wrote: On 08/04/16 09:06, Chris Johns wrote: I assume the microsecond, nanosecond and tick per sec values all need to agree. Does anything check this is the case and raise a fatal error if they do not? Currently nobody checks this. Should we check this via an _Assert()? If we add new fatal errors, it will get difficult. We need to test it. Yes an assert is perfect. It is a hard config error. The _Assert() is only active in case you use RTEMS_DEBUG. The Configuration is read-only. We would have to avoid to create a corrupt Configuration and this is very bad. It is not recommended anyone manually create their own Configuration table but there is nothing that says you _have_ to use confdefs.h. I do remember the pre-confdefs days. If we create a dependence we should ensure things are within spec before continuing. I don't think its feasible to avoid . Its now the only way to create a configuration. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Move POSIX network headers like etc. to Newlib?
On 08/04/16 04:22, Chris Johns wrote: On 8/04/2016 12:37 AM, Joel Sherrill wrote: Chris and I have discussed at least some of the network services being considered packages beyond the stack. Stuff like httpd, ftpd, and telnetd should be able to work with either stack. Having one instance of those to maintain would be great. I'm happy to see all this happen. Hopefully it can show up in digestable pieces. We need to maintain our current functionality and I am prepared to bridge but not abandon. The libbsd stack has made progress but does not support as much as the old stack does. Until it does I feel we need to keep the old stack going and to support it. The old stack is still a valid option since it uses considerably less memory than the new stack. To me this means adding headers to newlib requires the in-tree stack and libbsd work with out impacting users and existing applications. If I understand what is bring proposed any suitable networking software should be able to be built against just the compiler, newlib etc and it does not need a built and installed RTEMS with a specific networking implementation. This means networking could become a link time setting. An interesting challenge. Yes, this is the goal. Sebastian, I know you have talked about libressl, but it is still not clear to me why doing this is needed. Do you have a specific use case? Its not needed, but would simplify things. We want to update the mongoose HTTP server to support HTTPS. We also want to use it with the old and new stack. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[examples-v2 1/2] Compile filesystem testcase
Support compiling filesystem testcases. If not, filesystem testcases will not be compiled. Signed-off-by: Peng Fan --- Makefile| 2 +- filesystem/Makefile | 5 + 2 files changed, 6 insertions(+), 1 deletion(-) create mode 100644 filesystem/Makefile diff --git a/Makefile b/Makefile index 95d08fb..99b83e3 100644 --- a/Makefile +++ b/Makefile @@ -3,7 +3,7 @@ include $(RTEMS_CUSTOM) include $(RTEMS_SHARE)/make/directory.cfg SUBDIRS=classic_api posix_api hello led misc ticker file_io \ - benchmarks + benchmarks filesystem # Monitor Specific Examples SUBDIRS += uboot diff --git a/filesystem/Makefile b/filesystem/Makefile new file mode 100644 index 000..1267598 --- /dev/null +++ b/filesystem/Makefile @@ -0,0 +1,5 @@ +include $(RTEMS_MAKEFILE_PATH)/Makefile.inc +include $(RTEMS_CUSTOM) +include $(RTEMS_SHARE)/make/directory.cfg + +SUBDIRS = fat_ramdisk -- 2.6.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[examples-v2 2/2] fat_ramdisk: define POSIX keys number
define POSIX KEYS and PAIRS to 16, otherwise met: " pthread_setspecific(shell_current_env_key) " Signed-off-by: Peng Fan --- filesystem/fat_ramdisk/init.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/filesystem/fat_ramdisk/init.c b/filesystem/fat_ramdisk/init.c index 2fff705..62721f1 100644 --- a/filesystem/fat_ramdisk/init.c +++ b/filesystem/fat_ramdisk/init.c @@ -130,6 +130,9 @@ rtems_task Init( /* configuration */ +#define CONFIGURE_MAXIMUM_POSIX_KEYS 16 +#define CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS 16 + #define CONFIGURE_SHELL_COMMANDS_INIT #define CONFIGURE_SHELL_COMMANDS_ALL #define CONFIGURE_SHELL_MOUNT_MSDOS -- 2.6.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 02/12] score: Add ticks per second to configuration
On 8/04/2016 6:30 PM, Sebastian Huber wrote: The _Assert() is only active in case you use RTEMS_DEBUG. Then that is no good. I don't think its feasible to avoid . Its now the only way to create a configuration. Sorry, but I do not like confdefs getting these values in this way. This is not a great long term solution. Easy to add very hard to remove. Maybe you need make some score level variables and compute the values during configuration. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Move POSIX network headers like etc. to Newlib?
On 8/04/2016 6:34 PM, Sebastian Huber wrote: On 08/04/16 04:22, Chris Johns wrote: On 8/04/2016 12:37 AM, Joel Sherrill wrote: Chris and I have discussed at least some of the network services being considered packages beyond the stack. Stuff like httpd, ftpd, and telnetd should be able to work with either stack. Having one instance of those to maintain would be great. I'm happy to see all this happen. Hopefully it can show up in digestable pieces. We need to maintain our current functionality and I am prepared to bridge but not abandon. The libbsd stack has made progress but does not support as much as the old stack does. Until it does I feel we need to keep the old stack going and to support it. The old stack is still a valid option since it uses considerably less memory than the new stack. I agree. To me this means adding headers to newlib requires the in-tree stack and libbsd work with out impacting users and existing applications. If I understand what is bring proposed any suitable networking software should be able to be built against just the compiler, newlib etc and it does not need a built and installed RTEMS with a specific networking implementation. This means networking could become a link time setting. An interesting challenge. Yes, this is the goal. Awesome. Sebastian, I know you have talked about libressl, but it is still not clear to me why doing this is needed. Do you have a specific use case? Its not needed, but would simplify things. Great. We want to update the mongoose HTTP server to support HTTPS. Does this mean we have forked mongoose? Maybe it needs to be called something else if this happens. We also want to use it with the old and new stack. This is great. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Move POSIX network headers like etc. to Newlib?
On 08/04/16 11:25, Chris Johns wrote: We want to update the mongoose HTTP server to support HTTPS. Does this mean we have forked mongoose? Maybe it needs to be called something else if this happens. Since mongoose is in the RTEMS sources we already forked it. Upstream mongoose was forked after the license change. We plan to update it to this variant: https://sourceforge.net/projects/civetweb/ -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 02/12] score: Add ticks per second to configuration
On 08/04/16 11:22, Chris Johns wrote: I don't think its feasible to avoid . Its now the only way to create a configuration. Sorry, but I do not like confdefs getting these values in this way. This is not a great long term solution. Easy to add very hard to remove. Maybe you need make some score level variables and compute the values during configuration. In this case they are no longer read-only. One way to test it would be to use #define CONFIGURE_MICROSECONDS_PER_TICK 10 and exploit the limited integer ranges. Doesn't work if we check this configuration error in . -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Move POSIX network headers like etc. to Newlib?
On Fri, Apr 8, 2016 at 5:32 AM, Sebastian Huber wrote: > > > On 08/04/16 11:25, Chris Johns wrote: >>> >>> We want to update the >>> mongoose HTTP server to support HTTPS. >> >> >> Does this mean we have forked mongoose? Maybe it needs to be called >> something else if this happens. > > > Since mongoose is in the RTEMS sources we already forked it. Upstream > mongoose was forked after the license change. We plan to update it to this > variant: > > https://sourceforge.net/projects/civetweb/ > Great ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [examples-v2 1/2] Compile filesystem testcase
you can remove --signed-off-by do you know if the filesystem testcases are compiled correctly when using the rtems_waf approach to building examples-v2? On Fri, Apr 8, 2016 at 4:33 AM, Peng Fan wrote: > Support compiling filesystem testcases. > If not, filesystem testcases will not be compiled. > > Signed-off-by: Peng Fan > --- > Makefile| 2 +- > filesystem/Makefile | 5 + > 2 files changed, 6 insertions(+), 1 deletion(-) > create mode 100644 filesystem/Makefile > > diff --git a/Makefile b/Makefile > index 95d08fb..99b83e3 100644 > --- a/Makefile > +++ b/Makefile > @@ -3,7 +3,7 @@ include $(RTEMS_CUSTOM) > include $(RTEMS_SHARE)/make/directory.cfg > > SUBDIRS=classic_api posix_api hello led misc ticker file_io \ > - benchmarks > + benchmarks filesystem > > # Monitor Specific Examples > SUBDIRS += uboot > diff --git a/filesystem/Makefile b/filesystem/Makefile > new file mode 100644 > index 000..1267598 > --- /dev/null > +++ b/filesystem/Makefile > @@ -0,0 +1,5 @@ > +include $(RTEMS_MAKEFILE_PATH)/Makefile.inc > +include $(RTEMS_CUSTOM) > +include $(RTEMS_SHARE)/make/directory.cfg > + > +SUBDIRS = fat_ramdisk > -- > 2.6.2 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [examples-v2 2/2] fat_ramdisk: define POSIX keys number
looks good to me On Fri, Apr 8, 2016 at 4:33 AM, Peng Fan wrote: > define POSIX KEYS and PAIRS to 16, otherwise met: > " > pthread_setspecific(shell_current_env_key) > " > > Signed-off-by: Peng Fan > --- > filesystem/fat_ramdisk/init.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/filesystem/fat_ramdisk/init.c b/filesystem/fat_ramdisk/init.c > index 2fff705..62721f1 100644 > --- a/filesystem/fat_ramdisk/init.c > +++ b/filesystem/fat_ramdisk/init.c > @@ -130,6 +130,9 @@ rtems_task Init( > > /* configuration */ > > +#define CONFIGURE_MAXIMUM_POSIX_KEYS 16 > +#define CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS 16 > + > #define CONFIGURE_SHELL_COMMANDS_INIT > #define CONFIGURE_SHELL_COMMANDS_ALL > #define CONFIGURE_SHELL_MOUNT_MSDOS > -- > 2.6.2 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [examples-v2 1/2] Compile filesystem testcase
Hi Gedare, I met error when `waf`: "ImportError: No module named rtems_waf.rtems" This patch will not be accpetted, if switch to use waf? If you plan to accpet this patch, I can discard signed off and send out V2. Thanks, Peng. 2016-04-08 19:55 GMT+08:00 Gedare Bloom : > you can remove --signed-off-by > > do you know if the filesystem testcases are compiled correctly when > using the rtems_waf approach to building examples-v2? > > On Fri, Apr 8, 2016 at 4:33 AM, Peng Fan wrote: > > Support compiling filesystem testcases. > > If not, filesystem testcases will not be compiled. > > > > Signed-off-by: Peng Fan > > --- > > Makefile| 2 +- > > filesystem/Makefile | 5 + > > 2 files changed, 6 insertions(+), 1 deletion(-) > > create mode 100644 filesystem/Makefile > > > > diff --git a/Makefile b/Makefile > > index 95d08fb..99b83e3 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -3,7 +3,7 @@ include $(RTEMS_CUSTOM) > > include $(RTEMS_SHARE)/make/directory.cfg > > > > SUBDIRS=classic_api posix_api hello led misc ticker file_io \ > > - benchmarks > > + benchmarks filesystem > > > > # Monitor Specific Examples > > SUBDIRS += uboot > > diff --git a/filesystem/Makefile b/filesystem/Makefile > > new file mode 100644 > > index 000..1267598 > > --- /dev/null > > +++ b/filesystem/Makefile > > @@ -0,0 +1,5 @@ > > +include $(RTEMS_MAKEFILE_PATH)/Makefile.inc > > +include $(RTEMS_CUSTOM) > > +include $(RTEMS_SHARE)/make/directory.cfg > > + > > +SUBDIRS = fat_ramdisk > > -- > > 2.6.2 > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 02/12] score: Add ticks per second to configuration
On 8/04/2016 7:34 PM, Sebastian Huber wrote: On 08/04/16 11:22, Chris Johns wrote: I don't think its feasible to avoid . Its now the only way to create a configuration. Sorry, but I do not like confdefs getting these values in this way. This is not a great long term solution. Easy to add very hard to remove. Maybe you need make some score level variables and compute the values during configuration. In this case they are no longer read-only. Yes and holding RAM base computed values does use a couple of ints. Is there another reason they need to be read only? This change exposes implementation details unrelated to the configuration table. I cannot see a way we can avoid this with out having internal intermediate values. What is being proposed is an optimization and one worth doing but it exposes an optimization detail in an unfortunate way. If the implementation changes and these values are no longer needed can we remove them? We have no control on who uses them once we add them. One way to test it would be to use #define CONFIGURE_MICROSECONDS_PER_TICK 10 and exploit the limited integer ranges. Doesn't work if we check this configuration error in . A concern for me is the separation of the definition and the management. As a compromise maybe documenting the fields as generated would help and then provide a macro in the configuration table header to set the user visible value which then sets the generated values. I would prefer not to pollute the table. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
