<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 9, 2020 at 8:57 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">On Thu, Jul 9, 2020 at 9:24 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
><br>
> On Wed, Jul 8, 2020 at 10:08 PM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Wed, Jul 8, 2020 at 6:56 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
> >><br>
> >> On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber<br>
> >> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> >> ><br>
> >> > On 08/07/2020 14:43, Utkarsh Rai wrote:<br>
> >> ><br>
> >> > > Hello,<br>
> >> > > For my GSoC project, I have to provide high-level APIs for sharing<br>
> >> > > isolated stacks.<br>
> >> > > The POSIX compliant high-level way of sharing stacks can be to create<br>
> >> > > a shared memory object of the stack to be shared through shm_open and<br>
> >> > > then mmap that to the address space of the current stack. My doubt is,<br>
> >> > > shm_open() takes the path-name of the shared memory object. Since this<br>
> >> > > is a high-level API, how does the user 'convert' the stack address to<br>
> >> > > a shared memory object name?<br>
> >> > Do we need any POSIX compatibility for this? What would you do in a<br>
> >> > POSIX environment? You first get some memory, then hand it over to<br>
> >> > shm_open() to get a file descriptor, then use the file descriptor in<br>
> >> > mmap(), then use this for pthread_attr_setstack() and whatever?<br>
> >><br>
> >> Yes, but the way to name objects is not set by posix.<br>
> >><br>
> >> We need to provide our own way of translating an address into a name.<br>
> >><br>
> >> > ><br>
> >> > > Dr.Gedare mentioned that one way to deal with naming would be<br>
> >> > > something like Mr.Sebastian has been doing with specifications. From<br>
> >> > > what I could gather, it is a hierarchical way of representing<br>
> >> > > objects(Though, I am not very sure if  I understand this accurately).<br>
> >> > > How can something like this be implemented for naming stack-addresses?<br>
> >> > I am not sure if the specification of RTEMS is helpful in this context.<br>
> >><br>
> >> I should have provided a little bit more guidance. I was thinking out<br>
> >> loud in yesterday's IRC meeting. My thought was more along the lines<br>
> >> of looking at how UIDs/naming should be done, and that specs had to<br>
> >> solve a naming problem. However the static nature of specs is not a<br>
> >> great fit to this problem.<br>
> >><br>
> >> Actually, what is a good model would be something like /proc or<br>
> >> Linux's sysfs. An IMFS filesystem that exports task information could<br>
> >> be used to name memory regions. (It could eventually supplant<br>
> >> task-based statistics reporting too.)<br>
> >><br>
> >> Another idea I had though, which seems to have been lost in the<br>
> >> shuffle, is to look at how the object names work in RTEMS and see if<br>
> >> we can add some fixed relationships, e.g., task_name # stack.<br>
> >><br>
> >> I think we should start by just treating the entire task stack as a<br>
> >> single named object; either it is all shared, or none of it is shared.<br>
> >> This will be easier to implement and also more widely supported by<br>
> >> simpler MPU/MMU hardware. Later on, we can consider extending the<br>
> >> namespace with 'offsets' /taskfs/IDLE/stack/00000A28<br>
> >> could be a location at byte A28 offset from the start of the stack of<br>
> >> the IDLE task.<br>
> >><br>
> ><br>
> > I have a few questions -<br>
> ><br>
> > > 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?<br>
> ><br>
> We may want both to work. You definitely want to have the<br>
> address->name working though, at the very least with the base address<br>
> returned by pthread_attr_getstack, but you might also want to be able<br>
> to map any address in a task's stack to the stack's "name". I'm not<br>
> sure if that is needed yet, but keep it in mind as a possible<br>
> extension later to use an address interval instead of a fixed base<br>
> address.<br>
><br>
<br>
One more clarification, the "name to address" conversion should be<br>
done within the shm+mmap implementation. shm takes a name and returns<br>
a fd, mmap takes an fd and returns an address.<br></blockquote><div><br></div><div>Got it. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > > 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?<br>
> ><br>
><br>
> No, I'm thinking one name for each task's stack. If you have 10 tasks,<br>
> you'd have 10 names.</blockquote><div><br></div><div>Ok, so that means we can have naming like this -</div><div>For an idle thread stack address we have ->/taskfs/IDLE, for a POSIX thread address we have -> /taskfs/"thread_id". Where we maintain a table for the name and its corresponding address?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> Each allocated task stack is logically a separate region within the<br>
> pool. For simple MPU hardware, it may not be possible to share<br>
> arbitrary task stacks, but in that case the implementation can just<br>
> ignore the name and share the entire pool if that is preferred, or<br>
> return an error. (The behavior could be configurable, maybe.)<br>
><br>
> >><br>
> >> Gedare<br>
</blockquote></div></div>