About Thread_Cancel

Hi, Can someone please give a brief overview of what these three lines aim to achieve: } else if ( _Thread_Is_life_change_allowed( previous ) ) { _Thread_Add_life_change_request( the_thread ); _Thread_State_release( the_thread, _context ); _Thread_Finalize_life_change( the_thread,

Re: Unchecked return value on third party code

On 23/02/2021 16:23, Joel Sherrill wrote: cpukit/dtc/libfdt/fdt_rw.c | 2 +- The libfdt has an active upstream, so I would report this issue on their mailing list. This is a library I update occasionally. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email:

Re: How do we know what priority of the Init task is?

On 23/02/2021 23:41, Chris Johns wrote: On 24/2/21 9:26 am, dufa...@hda.com wrote: I re-read Joel's mail and I agree, the priority should be left ridiculously low (as it is now) or maybe set in the middle (but why bother?). I was thinking about matching classic RTEMS behavior. I don't think

Re: motorola_powerpc waf vs autoconf difference

On 24/02/2021 06:58, Chris Johns wrote: I have noticed a difference in the build of RTEMS 6 waf compared to RTEMS 5 and autoconf. The bootloader object files are not built with the code and data section options. This is preferred and I like it but I thought I would ask if this was intended?

[5 PATCH] powerpc/motorola_power: Link all text sections into the executable image

From: Chris Johns - The change to building all code with code and data sections means we have a section per function. Make sure all functions are placed in the text section. Closes #4266 --- bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds | 2 +- 1 file changed, 1 insertion(+), 1

motorola_powerpc waf vs autoconf difference

Hello, I have noticed a difference in the build of RTEMS 6 waf compared to RTEMS 5 and autoconf. The bootloader object files are not built with the code and data section options. This is preferred and I like it but I thought I would ask if this was intended? Thanks Chris

Re: How do we know what priority of the Init task is?

On 24/2/21 9:26 am, dufa...@hda.com wrote: > I re-read Joel's mail and I agree, the priority should be left ridiculously > low (as it is now) or maybe set in the middle (but why bother?). > > I was thinking about matching classic RTEMS behavior. I don't think it > matters in POSIX. The

Re: How do we know what priority of the Init task is?

I re-read Joel's mail and I agree, the priority should be left ridiculously low (as it is now) or maybe set in the middle (but why bother?). I was thinking about matching classic RTEMS behavior. I don't think it matters in POSIX. > On Feb 23, 2021, at 17:12 , Peter Dufault wrote: > > Signed

Re: How do we know what priority of the Init task is?

A few notes. All are my understanding and IMHO. - The reason that VRTX and other ancient RTOS's use 1 as the highest priority was the prevalence of "find first bit set" instructions. With e.g. 32 priorities you could in one instruction find the highest priority object that has something in

Re: [PATCH v4 1/2] bsps/beagle: Adding QEP driver support to BeagleBoneBlack BSP

On 23/2/21 7:18 pm, James Fitzsimons wrote: > --- > bsps/arm/beagle/headers.am | 2 + > bsps/arm/beagle/include/bsp/bbb-pwm.h | 11 - > bsps/arm/beagle/include/bsp/pwmss.h | 54 +++ > bsps/arm/beagle/include/bsp/qep.h | 382 >

Re: Unchecked return value on third party code

On 24/2/21 7:45 am, Joel Sherrill wrote: > On Tue, Feb 23, 2021, 2:36 PM Chris Johns > wrote: > > On 24/2/21 3:29 am, Christian MAUDERER wrote: > > Yes, I know. Upstream loops can be quite time consuming. I'm waiting > since > about > > half a year that

Re: Device Drivers Which Include mkdir("/dev")

On 24/2/21 2:18 am, Joel Sherrill wrote: > On Tue, Feb 23, 2021 at 2:52 AM Daniel Hellstrom > wrote: > I think the main reason why the mkdir() is called in the first place, from > for example rasta-io driver, is that once other drivers register their >

Re: Unchecked return value on third party code

On Tue, Feb 23, 2021, 2:36 PM Chris Johns wrote: > On 24/2/21 3:29 am, Christian MAUDERER wrote: > > Yes, I know. Upstream loops can be quite time consuming. I'm waiting > since about > > half a year that a FreeBSD patch for the i.MX6ULL SDHCI gets reviewed > (after > > someone here suggested it

Re: Unchecked return value on third party code

On 24/2/21 3:29 am, Christian MAUDERER wrote: > Yes, I know. Upstream loops can be quite time consuming. I'm waiting since > about > half a year that a FreeBSD patch for the i.MX6ULL SDHCI gets reviewed (after > someone here suggested it should go upstream). It's not a chip that is used in >

Re: How do we know what priority of the Init task is?

On Tue, Feb 23, 2021, 11:14 AM Heinz Junkes wrote: > Thank you for the detailed explanation. I may have asked my question > incorrectly. > > If I choose POSIX_Init for RTEMS the Init process has a very low priority > and if I use > the normal (RTEMS) Init a very high priority. This does not fit

Re: How do we know what priority of the Init task is?

Thank you for the detailed explanation. I may have asked my question incorrectly. If I choose POSIX_Init for RTEMS the Init process has a very low priority and if I use the normal (RTEMS) Init a very high priority. This does not fit in my opinion. Shouldn't the POSIX_Init - process have the

Re: Unchecked return value on third party code

Am 23.02.21 um 17:14 schrieb Joel Sherrill: On Tue, Feb 23, 2021 at 9:50 AM Christian MAUDERER > wrote: Hello Joel, Am 23.02.21 um 16:23 schrieb Joel Sherrill: > Hi > > Ryan has wandered into the land of third party code

Re: Unchecked return value on third party code

On Tue, Feb 23, 2021 at 9:50 AM Christian MAUDERER < christian.maude...@embedded-brains.de> wrote: > Hello Joel, > > Am 23.02.21 um 16:23 schrieb Joel Sherrill: > > Hi > > > > Ryan has wandered into the land of third party code and Coverity issues. > > It is not a very welcoming land and we need

Re: Unchecked return value on third party code

Hello Joel, Am 23.02.21 um 16:23 schrieb Joel Sherrill: Hi Ryan has wandered into the land of third party code and Coverity issues. It is not a very welcoming land and we need to decide what we want to do as a project. I put one In these cases, we have a few patterns to fall back on. There

Unchecked return value on third party code

Hi Ryan has wandered into the land of third party code and Coverity issues. It is not a very welcoming land and we need to decide what we want to do as a project. I put one In these cases, we have a few patterns to fall back on. There are basically a few choices here: + ignore third party code

Re: Device Drivers Which Include mkdir("/dev")

On Tue, Feb 23, 2021 at 2:52 AM Daniel Hellstrom wrote: > Hi, > > I think the main reason why the mkdir() is called in the first place, from > for example rasta-io driver, is that once other drivers register their > device pciN.devM into the /dev/pciboardN/devM it would fail if the the >

Re: How do we know what priority of the Init task is?

On Tue, Feb 23, 2021 at 4:25 AM Heinz Junkes wrote: > what I have just never understood > > POSIX Prio 2 ist LOW Priority > RTEMS Prio 1 is HIGH Priority > In general, RTOS threading APIs tended to use 1 as a high priority. The RTEMS Classic API based on pSOS+, VxWorks, and VRTX32 which

Re: How do we know what priority of the Init task is?

what I have just never understood POSIX Prio 2 ist LOW Priority RTEMS Prio 1 is HIGH Priority Heinz > On 23. Feb 2021, at 09:17, Sebastian Huber > wrote: > > On 23/02/2021 08:36, Heinz Junkes wrote: > >> I would have a similar question ;-) >> >> What is the priority of the POSIX_Init -

Re: Device Drivers Which Include mkdir("/dev")

Hi, I think the main reason why the mkdir() is called in the first place, from for example rasta-io driver, is that once other drivers register their device pciN.devM into the /dev/pciboardN/devM it would fail if the the directory /dev/pciboardN has not been created. So it is an attempt to

Re: [PATCH v3 0/1] Resubmission of patch previously submitted Sept 2020

Hi Chris, I've just submitted v4 with those licences updated. I hope I've done it correctly. Cheers, James On Tue, 23 Feb 2021 at 10:23, Chris Johns wrote: > Hi James, > > Thanks for the patch. It is close. Could I ask if all the source files > from you > please be updated to the latest

[PATCH v4 2/2] bsps/beagle: Updating licences to latest BSD 2 clause

--- bsps/arm/beagle/include/bsp/bbb-pwm.h | 28 +++ bsps/arm/beagle/include/bsp/pwmss.h | 30 - bsps/arm/beagle/include/bsp/qep.h | 32 ++- bsps/arm/beagle/pwm/pwm.c | 27 ++

[PATCH v4 1/2] bsps/beagle: Adding QEP driver support to BeagleBoneBlack BSP

--- bsps/arm/beagle/headers.am | 2 + bsps/arm/beagle/include/bsp/bbb-pwm.h | 11 - bsps/arm/beagle/include/bsp/pwmss.h | 54 +++ bsps/arm/beagle/include/bsp/qep.h | 382 bsps/arm/beagle/pwm/pwm.c | 60 +---

Re: How do we know what priority of the Init task is?

On 23/02/2021 08:36, Heinz Junkes wrote: I would have a similar question ;-) What is the priority of the POSIX_Init - Task (as Posix-Prio)? There is no option to configure the priority of the POSIX initialization thread, so the default priority of 2 is used, see