<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 19, 2020 at 11:39 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Utkarsh,<br>
<br>
On Thu, Nov 19, 2020 at 4:59 AM Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
><br>
> On 19/11/2020 11:47, Utkarsh Rai wrote:<br>
><br>
> >     There are a couple of other areas in RTEMS in which the stack of<br>
> >     another<br>
> >     thread may be accessed (events, message queues, signals). How did you<br>
> >     solve this?<br>
> ><br>
> ><br>
> > When we enable the thread stack protection, all the services in which<br>
> > a different stack is accessed becomes invalid ( This will have to be<br>
> > documented  ).<br>
> > The user has to share the stack of the threads that will be using<br>
> > services like message queue with each other from the application using<br>
> > mmap(),shm_open(), etc. (This was a part of the work I did during GSoC).<br>
><br>
> This is a bit too restrictive from my point of view. Consider for<br>
> example this very common use of rtems_event_receive():<br>
><br>
> rtems_event_set events;<br>
><br>
> rtems_event_receive(..., &events, ...);<br>
><br>
Let's try to keep the technical discussion on the mailing list. </blockquote><div><br></div><div>Oh sorry, I somehow forgot to cc the mailing list.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I<br>
agree with Sebastian's point here, which is well taken. Maybe it would<br>
be good for you to determine the set of tests and from that the<br>
features that break with strict task isolation. This way, we can<br>
determine whether each is better handled as imposing a requirement on<br>
the user, e.g., to mmap/share explicitly in case they want to pass<br>
data (such as with an mq), or if RTEMS needs to make it work<br>
implicitly such as with event sets and maybe these iterators.<br>
<br>
Gedare<br></blockquote><div><br></div><div><br></div><div>Ok.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> --<br>
> embedded brains GmbH<br>
> Sebastian HUBER<br>
> Dornierstr. 4<br>
> 82178 Puchheim<br>
> Germany<br>
> email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
> Phone: +49-89-18 94 741 - 16<br>
> Fax:   +49-89-18 94 741 - 08<br>
> PGP: Public key available on request.<br>
><br>
> embedded brains GmbH<br>
> Registergericht: Amtsgericht München<br>
> Registernummer: HRB 157899<br>
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
> Unsere Datenschutzerklärung finden Sie hier: <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
><br>
</blockquote></div></div>