Re: [PATCH] build: Fix dependencies for start and asm files

On 17/9/20 4:26 pm, Sebastian Huber wrote: > On 17/09/2020 08:21, Chris Johns wrote: >> On 17/9/20 4:11 pm, Sebastian Huber wrote: >>> On 17/09/2020 08:07, Chris Johns wrote: On 17/9/20 3:57 pm, Sebastian Huber wrote: > +@feature("explicit_asm_target") explicit_asm? >>> asm_explicit_t

Re: [PATCH] build: Fix dependencies for start and asm files

On 17/09/2020 08:21, Chris Johns wrote: On 17/9/20 4:11 pm, Sebastian Huber wrote: On 17/09/2020 08:07, Chris Johns wrote: On 17/9/20 3:57 pm, Sebastian Huber wrote: Add explicit asm target feature.  Add a build start file node list and use it as a test program dependency. Close #3846. Clos

Re: [PATCH] build: Fix dependencies for start and asm files

On 17/9/20 4:11 pm, Sebastian Huber wrote: > On 17/09/2020 08:07, Chris Johns wrote: > >> >> On 17/9/20 3:57 pm, Sebastian Huber wrote: >>> Add explicit asm target feature.  Add a build start file node list and >>> use it as a test program dependency. >>> >>> Close #3846. >>> Close #4080. >>> ---

Re: [PATCH] build: Fix dependencies for start and asm files

On 17/09/2020 08:07, Chris Johns wrote: On 17/9/20 3:57 pm, Sebastian Huber wrote: Add explicit asm target feature. Add a build start file node list and use it as a test program dependency. Close #3846. Close #4080. --- wscript | 41 - 1 file change

Re: [PATCH] build: Fix dependencies for start and asm files

On 17/9/20 3:57 pm, Sebastian Huber wrote: > Add explicit asm target feature. Add a build start file node list and > use it as a test program dependency. > > Close #3846. > Close #4080. > --- > wscript | 41 - > 1 file changed, 36 insertions(+), 5 delet

Re: [PATCH] build: Fix dependencies for start and asm files

Hello, On 17/09/2020 07:57, Sebastian Huber wrote: Add explicit asm target feature. Add a build start file node list and use it as a test program dependency. Close #3846. Close #4080. I only have a vague feeling what these changes do. Thomas Nagy provided me with a couple of code snippets a

[PATCH] build: Fix dependencies for start and asm files

Add explicit asm target feature. Add a build start file node list and use it as a test program dependency. Close #3846. Close #4080. --- wscript | 41 - 1 file changed, 36 insertions(+), 5 deletions(-) diff --git a/wscript b/wscript index 2e42918ebb..d47f

Re: [PATCH v1 2/6] waf: Add path-mappings feature

On 16/9/20 8:06 pm, jan.som...@dlr.de wrote: > Hi Chris, > >> -Original Message- >> From: Chris Johns >> Sent: Thursday, September 10, 2020 6:44 AM >> To: Sommer, Jan ; devel@rtems.org >> Subject: Re: [PATCH v1 2/6] waf: Add path-mappings feature >> >> On 15/8/20 5:57 am, Jan Sommer wrote

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

On 17/9/20 9:50 am, Joel Sherrill wrote: > On Wed, Sep 16, 2020, 6:43 PM Chris Johns > wrote: > > On 16/9/20 11:42 pm, Joel Sherrill wrote: > > snprintf() is a safe method and I strongly disagree with the blanket > replacement > > of many safe methods with

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

On Wed, Sep 16, 2020, 6:43 PM Chris Johns wrote: > On 16/9/20 11:42 pm, Joel Sherrill wrote: > > snprintf() is a safe method and I strongly disagree with the blanket > replacement > > of many safe methods with memcpy(). > > > > Based on what POSIX profiles snprintf() is included in and the safety

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

On 16/9/20 11:42 pm, Joel Sherrill wrote: > snprintf() is a safe method and I strongly disagree with the blanket > replacement > of many safe methods with memcpy(). > > Based on what POSIX profiles snprintf() is included in and the safety and > security requirements those profiles are designed to

Re: [PATCH v5 0/7] Add rtems_task_construct()

Looks good. Thanks for your patience as we worked through this change. I think the outcome is solid and reflects the efforts made. Chris On 17/9/20 12:49 am, Sebastian Huber wrote: > v2: > > Rename function from rtems_task_build() to > rtems_task_create_from_config(). Add RTEMS_TASK_STORAGE_AL

Re: RTEMS BSP Builder and New/Old Build System

On 17/9/20 8:12 am, Joel Sherrill wrote: > Just noting that it would be nice to have a transition period where RTEMS BSP > Builder supported both build systems for comparison purposes. I prefer this be as short as possible. What about 1st Nov 2020? It is not clear what the criteria is to trigger

RTEMS BSP Builder and New/Old Build System

Hi Just noting that it would be nice to have a transition period where RTEMS BSP Builder supported both build systems for comparison purposes. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[RTEMS-libBSD OFW v1] dev/ofw: Use RTEMS OFW FDT implementation

This commit modifies the OFW interface to the RTEMS FDT implementation instead of the default FreeBSD. --- freebsd/sys/dev/ofw/openfirm.c| 2 ++ freebsd/sys/dev/ofw/openfirm.h| 9 .../machine/rtems-bsd-kernel-namespace.h | 22 --- 3 f

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

Hello, Sorry for the delay, I was a bit occupied with my university work. Now since the new build system is merged I would like to get my GSoC work merged too. The goal of this series patches is to implement the OFW API into RTEMS and modify libBSD to use this RTEMS API instead of its own. Thank

[PATCH v1 2/2] libtests/ofw01: Added a test for RTEMS OFW

This commit adds a basic test that tests all the implemented RTEMS OFW functions. --- spec/build/testsuites/libtests/grp.yml | 2 + spec/build/testsuites/libtests/ofw01.yml | 21 +++ testsuites/libtests/ofw01/init.c | 187 +++ testsuites/libtests/ofw01/ofw01.doc

[PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

RTEMS OFW is a FDT only implementation of the OpenFirmWare interface. This API is created to be compatible with FreeBSD OpenFirmWare interface. The main intention is to make porting of FreeBSD drivers to RTEMS easier. Most functions implemented have an direct one-one mapping with the original OFW

Re: Strong APA scheduler testing

Hi, Sorry for the delay. My university tests were going on. So, I reran the test only for smptestsuites, and I have attached the log. The test says that smpfatal09 gives timeout, where when I ran the test with qemu, I get the following output: ---

Re: devel Digest, Vol 106, Issue 81

On Mon, Sep 14, 2020 at 5:30 PM wrote: > Send devel mailing list submissions to > devel@rtems.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.rtems.org/mailman/listinfo/devel > or, via email, send a message with subject or body 'help' to >

[PATCH v5 0/7] Add rtems_task_construct()

v2: Rename function from rtems_task_build() to rtems_task_create_from_config(). Add RTEMS_TASK_STORAGE_ALIGNMENT and RTEMS_TASK_STORAGE_SIZE(). Improve documentation. v3: Add CONFIGURE_TASKS_CREATED_FROM_CONFIG. Fix RTEMS_TASK_STORAGE_SIZE() if CPU_ALL_TASKS_ARE_FP == TRUE. v4: Add CONFIGUR

[PATCH v5 3/7] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

Add this application configuration option. This configuration option can be used to reserve space for the dynamic linking of modules with thread-local storage objects. Add RTEMS_TASK_STORAGE_ALIGNMENT to define the minium alignment of a thread-local storage size. Update #4074. --- cpukit/doxyge

[PATCH v5 2/7] rtems: Add RTEMS_ALIGN_UP()

Update #3959. Update #4074. --- cpukit/include/rtems/score/basedefs.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/cpukit/include/rtems/score/basedefs.h b/cpukit/include/rtems/score/basedefs.h index 4d16c88b49..c31b4ebef7 100644 --- a/cpukit/include/rtems/score/basedefs.h

[PATCH v5 4/7] rtems: Add rtems_task_construct()

In contrast to rtems_task_create() this function constructs a task with a user-provided task storage area. The new directive uses a configuration structure instead of individual parameters. Add RTEMS_TASK_STORAGE_SIZE() to calculate the recommended size of a task storage area based on the task at

[PATCH v5 1/7] rtems: Add RTEMS_ALIGN_DOWN()

Update #3959. Update #4074. --- cpukit/include/rtems/score/basedefs.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/cpukit/include/rtems/score/basedefs.h b/cpukit/include/rtems/score/basedefs.h index 5a7e4e4f31..4d16c88b49 100644 --- a/cpukit/include/rtems/score/basedefs.h

[PATCH v5 7/7] validation: rtems_task_construct() errors

This is the first test case generated from a specification item in the rtems-central repository. Update #3959. --- .../testsuites/validation/validation-0.yml|1 + .../validation/tc-task-construct-errors.c | 2367 + 2 files changed, 2368 insertions(+) create mode 10064

[PATCH v5 5/7] doxygen: Move top-level group definitions

Update #3959. --- cpukit/doxygen.h | 18 - cpukit/doxygen/top-level-groups.h | 44 +++ 2 files changed, 44 insertions(+), 18 deletions(-) create mode 100644 cpukit/doxygen/top-level-groups.h diff --git a/cpukit/doxygen.h b/cpukit/doxygen.h

[PATCH v5 6/7] validation: Add general purpose test suite

Add a general purpose test suite for validation tests. This is the first test suite generated from a specification item in the rtems-central repository. Update #3959. --- Doxyfile | 2 +- cpukit/doxygen/top-level-groups.h | 6 + spec/build/tes

Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

snprintf() is a safe method and I strongly disagree with the blanket replacement of many safe methods with memcpy(). Based on what POSIX profiles snprintf() is included in and the safety and security requirements those profiles are designed to meet, snprintf() is supported by RTOSes that can meet

RE: legacy stack or libbsd

>On 5/8/20 2:13 pm, Gedare Bloom wrote: >> On Tue, Aug 4, 2020 at 6:41 PM Chris Johns wrote: > >>> On 5/8/20 10:23 am, Chris Johns wrote: On 5/8/20 2:04 am, Heinz Junkes wrote: > Because the libbsd stack does not support some things yet (e.g. ntp) > I have PTP running on libbsd. I cu

RE: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

> -Original Message- > From: Sebastian Huber > Sent: Wednesday, September 16, 2020 12:30 PM > To: Sommer, Jan ; devel@rtems.org > Subject: Re: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes > smpfatal08 link > > On 16/09/2020 12:06, jan.som...@dlr.de wrote: > > > Is there

Re: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

On 16/09/2020 12:06, jan.som...@dlr.de wrote: Is there an easy way to only send the updated patch to the mailinglist or should I send in the full patch set with v2? It seems the patch set is already included in the RTEMS master. ___ devel mailing lis

RE: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

Hi Sebastian, Sure. Is there an easy way to only send the updated patch to the mailinglist or should I send in the full patch set with v2? Cheers, Jan > -Original Message- > From: Sebastian Huber > Sent: Tuesday, September 15, 2020 6:38 AM > To: Sommer, Jan ; devel@rtems.org > Subje

RE: [PATCH v1 2/6] waf: Add path-mappings feature

Hi Chris, > -Original Message- > From: Chris Johns > Sent: Thursday, September 10, 2020 6:44 AM > To: Sommer, Jan ; devel@rtems.org > Subject: Re: [PATCH v1 2/6] waf: Add path-mappings feature > > On 15/8/20 5:57 am, Jan Sommer wrote: > > - path-mappings allow to fix autogenerated includ

Re: New build system ready for testing

On 16/9/20 4:45 pm, Karel Gardas wrote: > Looks great, but on submit attempt I've been welcome by "Akismet says > content is spam" and I guess I solved math exercise well... I am sorry, I have no idea why that would happen. Chris ___ devel mailing list