Re: Memory Protection project interface details (GSoC 2020)

On Wed, May 13, 2020 at 10:53 AM Utkarsh Rai wrote: > > > > On Wed, May 13, 2020 at 8:11 PM Gedare Bloom wrote: >> >> On Wed, May 13, 2020 at 6:12 AM Utkarsh Rai wrote: >> > >> > >> > >> > On Wed, May 13, 2020 at 3:56 AM Joel Sherrill wrote: >> >> >> >> I hate to top post but I'm not sure

Re: Memory Protection project interface details (GSoC 2020)

On Wed, May 13, 2020 at 10:27 PM Joel Sherrill wrote: > > > On Wed, May 13, 2020 at 9:41 AM Gedare Bloom wrote: > >> On Wed, May 13, 2020 at 6:12 AM Utkarsh Rai >> wrote: >> > >> > >> > >> > On Wed, May 13, 2020 at 3:56 AM Joel Sherrill wrote: >> >> >> >> I hate to top post but I'm not sure

Re: GSoC: RTEMS directory for FreeBSD imports

Hello, This mail is to regain attention for this topic and also to discuss a few details regarding the porting process. In the previous thread, Sebastian mentioned that we will be hard wiring the OF functions with the FDT implementation. For reasons please have a look at previous thread.

Re: Memory Protection project interface details (GSoC 2020)

On Wed, May 13, 2020 at 9:41 AM Gedare Bloom wrote: > On Wed, May 13, 2020 at 6:12 AM Utkarsh Rai > wrote: > > > > > > > > On Wed, May 13, 2020 at 3:56 AM Joel Sherrill wrote: > >> > >> I hate to top post but I'm not sure where to insert this. > >> > >> As a first step, I would ensure that

Re: Memory Protection project interface details (GSoC 2020)

On Wed, May 13, 2020 at 8:11 PM Gedare Bloom wrote: > On Wed, May 13, 2020 at 6:12 AM Utkarsh Rai > wrote: > > > > > > > > On Wed, May 13, 2020 at 3:56 AM Joel Sherrill wrote: > >> > >> I hate to top post but I'm not sure where to insert this. > >> > >> As a first step, I would ensure that

Re: Memory Protection project interface details (GSoC 2020)

> On May 12, 2020, at 16:51 , Gedare Bloom wrote: > > On Tue, May 12, 2020 at 10:58 AM Utkarsh Rai wrote: >> >> >> >> On Tue, May 12, 2020 at 9:27 AM Gedare Bloom wrote: >>> >>> On Thu, May 7, 2020 at 9:59 PM Hesham Almatary >>> wrote: Hello Utkarsh, I'd suggest

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

Thanks for the good ideas. I have now replaced the accesses to the internal thread structure (real_priority, current_priority) with API - calls. One of the calls is from the pthread-library and therefore needs --enable-posix when creating the BSP. Calls used pthread_getschedparam

Re: Memory Protection project interface details (GSoC 2020)

On Wed, May 13, 2020 at 6:12 AM Utkarsh Rai wrote: > > > > On Wed, May 13, 2020 at 3:56 AM Joel Sherrill wrote: >> >> I hate to top post but I'm not sure where to insert this. >> >> As a first step, I would ensure that paging catches stack overflow errors. > > > I understand that any

Re: Adding fenv support for ARM

National free hint day!!! Look above the line that is reported. You will see __BEGIN_DECL. It isn't defined. It is intended to expand to the __cplusplus wrapper. After you fix this, you will sequentially find 2 other things to change in this file. Then we need to make a decision whether the

Help on how to configure for user-defined memory protection support (GSoC 2020)

Hello, My GSoC project, providing thread stack protection support, has to be a user-configurable feature. My question is, what would be the best way to implement this, my idea was to model it based on the existing system configuration

Re: Memory Protection project interface details (GSoC 2020)

On Wed, May 13, 2020 at 3:56 AM Joel Sherrill wrote: > I hate to top post but I'm not sure where to insert this. > > As a first step, I would ensure that paging catches stack overflow errors. > I understand that any thread-stack protection mechanism has to ensure against a stack overflow error,