Converting stack address to shared-memory object name

[Gedare Bloom]

On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber
<sebastian.huber at 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.

Gedare