On Sun, Aug 2, 2020 at 5:46 AM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: > > > > On Sat, Aug 1, 2020 at 10:51 PM Gedare Bloom <ged...@rtems.org> wrote: >> >> On Sat, Aug 1, 2020 at 10:38 AM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: >> > >> > This thread is an attempt to consolidate and resolve all the issues that >> > have been raised related to my patches- 1. >> > https://lists.rtems.org/pipermail/devel/2020-July/060675.html and 2. >> > https://lists.rtems.org/pipermail/devel/2020-July/061056.html. I intend to >> > first resolve all the issues through this thread( and probably convert >> > this into a blog-post ), before making any further changes. >> > >> > 1. Stack address name that needs to be passed to shm_open() - This was >> > briefly discussed here, and I believe the reason we still have issues with >> > this is because of my incorrect interpretation of what was suggested. My >> > idea was that we need to assign a name like "/taskfs/pid" to each stack >> > address on the creation of the thread. On looking around further, I >> > realize we can have the stack address name the same as the thread name. >> > >> ok. the /taskfs idea was more of a longer-term concept. I think it >> would require possibly an entire GSoC itself. It'd be nice though :) >> >> > 2. Switching out shared stacks- In my current implementation, removing >> > protected stacks is done through assembly code but the >> > '_Stackprotection_Context_switch' which switches out the shared stack is >> > difficult to implement in assembly. But we need to integrate the shared >> > stack switching in the context switching code as we don't have access to >> > executing thread attributes anywhere else. >> > >> I think the real problem here is that your code to switch stacks is >> too complicated. It would certainly be folly to try to implement >> linked list processing in assembly of the context switch, but you >> shouldn't need to be walking a linked list anyway. There are simpler >> solutions that would work just as well, including replacing the entire >> address space (e.g., switching the page table base register) or using >> an array to store the shared stack addresses and just iterating the >> array. > > > Ok, but this would mean that we can only share a set number of stacks with > each thread? >
Perhaps. You might be able to use an extendable array if the number of shared stacks is configurable. This again goes into the problem that configuration hasn't been solved yet. >> >> >> > 3. Integration of the 'Stackprotection_attr' structure with the thread and >> > stack control structure - The integration is a pretty straightforward >> > task, the difficulty lies in handling the attribute offset in the assembly >> > code, whereas having the 'Stackprotection_attr' just after the context >> > control attribute in the thread control structure makes handling the >> > offset relatively easy. >> > >> The Stack_Control is embedded already, you just need to calculate the >> location of Thread_Control.Start.Initial_stack first, and then offset >> within that structure. > > > I agree it's just that it is extra work and maybe I was being lazy :). Maybe. Sometimes it is better to pay now than later though. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
