On Wed, Jul 8, 2020 at 6:56 PM Gedare Bloom <ged...@rtems.org> wrote:
> On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: > > > > On 08/07/2020 14:43, Utkarsh Rai wrote: > > > > > Hello, > > > For my GSoC project, I have to provide high-level APIs for sharing > > > isolated stacks. > > > The POSIX compliant high-level way of sharing stacks can be to create > > > a shared memory object of the stack to be shared through shm_open and > > > then mmap that to the address space of the current stack. My doubt is, > > > shm_open() takes the path-name of the shared memory object. Since this > > > is a high-level API, how does the user 'convert' the stack address to > > > a shared memory object name? > > Do we need any POSIX compatibility for this? What would you do in a > > POSIX environment? You first get some memory, then hand it over to > > shm_open() to get a file descriptor, then use the file descriptor in > > mmap(), then use this for pthread_attr_setstack() and whatever? > > Yes, but the way to name objects is not set by posix. > > We need to provide our own way of translating an address into a name. > > > > > > > Dr.Gedare mentioned that one way to deal with naming would be > > > something like Mr.Sebastian has been doing with specifications. From > > > what I could gather, it is a hierarchical way of representing > > > objects(Though, I am not very sure if I understand this accurately). > > > How can something like this be implemented for naming stack-addresses? > > I am not sure if the specification of RTEMS is helpful in this context. > > I should have provided a little bit more guidance. I was thinking out > loud in yesterday's IRC meeting. My thought was more along the lines > of looking at how UIDs/naming should be done, and that specs had to > solve a naming problem. However the static nature of specs is not a > great fit to this problem. > > Actually, what is a good model would be something like /proc or > Linux's sysfs. An IMFS filesystem that exports task information could > be used to name memory regions. (It could eventually supplant > task-based statistics reporting too.) > > Another idea I had though, which seems to have been lost in the > shuffle, is to look at how the object names work in RTEMS and see if > we can add some fixed relationships, e.g., task_name # stack. > > I think we should start by just treating the entire task stack as a > single named object; either it is all shared, or none of it is shared. > This will be easier to implement and also more widely supported by > simpler MPU/MMU hardware. Later on, we can consider extending the > namespace with 'offsets' /taskfs/IDLE/stack/00000A28 > could be a location at byte A28 offset from the start of the stack of > the IDLE task. > > I have a few questions - > Users would get the stack address of the stack they want to share through pthread_attr_getstack(). Now, when they get the address they want to share, they would pass the appropriate name of this memory-region. What we have to provide is a mechanism to 'convert' this address to an appropriate name. Is this the accepted way or the other way round, i.e. the user passes a name as per a specified convention, and that name is 'converted' to a specific address? > When you say "treating the entire task stack as a single named object" does it mean that we assign a single name, say "task_stack" to the complete stack address space? In that case, how do we deal we the presence of multiple tasks that are allocated from the same pool of task stack? I understand that on a simpler MPU/MMU hardware it would make sense to specify names for each memory section (.txt- "text", .bss - "bss" etc.) but in this case, where we are sharing only selected thread-stacks, I suppose we will have to have a way to handle 'offsets' right from the start? > Gedare >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel