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? > > > 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 :).
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
