[PATCH] posix: Get real priority in pthread_getattr_np()

This is in line with pthread_setschedparam() and pthread_getschedparam(). Update #2514. --- cpukit/posix/src/pthreadgetattrnp.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/cpukit/posix/src/pthreadgetattrnp.c b/cpukit/posix/src/pthreadgetattrnp.c index

Re: Introduction of Priority_node structure (priority.h)

Hello Heinz, On 11/05/2020 10:54, Heinz Junkes wrote: The Priority_node structure was committed to the 4.10 branch of RTEMS in December 2017 (78b867e26d score: replace current and real priority with priority node). Do I have a possibility to know at compile time (in our case EPICS) if it is

Re: Memory Protection project interface details (GSoC 2020)

On Thu, May 7, 2020 at 9:59 PM Hesham Almatary wrote: > > Hello Utkarsh, > > I'd suggest you don't spend too much efforts on setting up BBB > hardware if you haven't already. Debugging on QEMU with GDB is way > easier, and you can consider either qemu-xilinx-zynq-a9 or rpi2 BSPs. > Later, you can

Re: Introduction of Priority_node structure (priority.h)

On Mon, May 11, 2020 at 9:27 AM Gedare Bloom wrote: > > On Mon, May 11, 2020 at 2:54 AM Heinz Junkes wrote: > > > > The Priority_node structure was committed to the 4.10 branch of RTEMS in > > December > > 2017 (78b867e26d score: replace current and real priority with priority > > node). > > >

Re: Introduction of Priority_node structure (priority.h)

On Mon, May 11, 2020 at 2:54 AM Heinz Junkes wrote: > > The Priority_node structure was committed to the 4.10 branch of RTEMS in > December > 2017 (78b867e26d score: replace current and real priority with priority node). > > Do I have a possibility to know at compile time (in our case EPICS)

Introduction of Priority_node structure (priority.h)

The Priority_node structure was committed to the 4.10 branch of RTEMS in December 2017 (78b867e26d score: replace current and real priority with priority node). Do I have a possibility to know at compile time (in our case EPICS) if it is present or not. Background: We had received the

Re: GSoC: RTEMS directory for FreeBSD imports

On 11/05/2020 09:11, Chris Johns wrote: > On 11/5/20 4:55 pm, Christian Mauderer wrote: >> On 11/05/2020 06:57, Chris Johns wrote: >>> >>> >>> On 11/5/20 2:03 pm, Niteesh G. S. wrote: On Mon, May 11, 2020 at 4:34 AM Chris Johns >>> > wrote: On 10/5/20

Re: GSoC: RTEMS directory for FreeBSD imports

On 11/5/20 4:55 pm, Christian Mauderer wrote: On 11/05/2020 06:57, Chris Johns wrote: On 11/5/20 2:03 pm, Niteesh G. S. wrote: On Mon, May 11, 2020 at 4:34 AM Chris Johns mailto:chr...@rtems.org>> wrote:     On 10/5/20 6:17 pm, Niteesh G. S. wrote: > This thread is a continuation of

Re: GSoC: RTEMS directory for FreeBSD imports

On 11/05/2020 06:57, Chris Johns wrote: > > > On 11/5/20 2:03 pm, Niteesh G. S. wrote: >> On Mon, May 11, 2020 at 4:34 AM Chris Johns > > wrote: >> >>     On 10/5/20 6:17 pm, Niteesh G. S. wrote: >> > This thread is a continuation of "GSoC 2020: Implementation of

Re: GSoC: RTEMS directory for FreeBSD imports

On 11/5/20 3:59 pm, Sebastian Huber wrote: On 11/05/2020 01:04, Chris Johns wrote: I am OK with some code being in rtems.git if there is a clear use outside of rtems-libbsd. FDT support is one use, another is the NFS client code in FreeBSD being used with the legacy stack (there are BSPs with

Re: GSoC: RTEMS directory for FreeBSD imports

On 11/05/2020 01:04, Chris Johns wrote: I am OK with some code being in rtems.git if there is a clear use outside of rtems-libbsd. FDT support is one use, another is the NFS client code in FreeBSD being used with the legacy stack (there are BSPs with only legacy driver support still in use)