Help in figuring out score objects in RTEMS and ticket #3131

Gedare Bloom gedare at rtems.org
Tue Jun 16 04:04:55 UTC 2020


On Mon, Jun 15, 2020 at 11:29 AM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>
>
>
>
> On Mon, Jun 15, 2020 at 6:46 PM Joel Sherrill <joel at rtems.org> wrote:
>>
>>
>>
>> On Wed, Jun 10, 2020 at 7:34 PM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>>>
>>> Hello,
>>> For my GSoC project, user-configurable thread stack protection, I need to track, allocate, and manipulate attributes of shared as well as protected stacks. Dr.Gedare suggested that tracking them with score objects would be a good idea. He also indicated a good place to start and understand score objects would be through this ticket.
>>>
>>> From the information that I could find in docs, my understanding of score objects is that they are a type of directive that helps introduce modularity to RTEMS as various types of RTEMS objects like message queues, semaphores, etc. can use the same set of directives for allocation/deallocation and control of their object types.
>>
>>
>> It is probably easier for you to think about the score as a collection of core classes that are reused across the public APIs. They do have strong modularity but they also ensure that the correct and optimized behavior is present across both the Classic and POSIX APIs. For example, a mutex can be optimized and made computer science correct just once and both the POSIX and Classic APIs benefit. Whether you call this layering, modularity, packaging, or classes is OK.
>>
>> If you look at the Doxygen, you will see there is even a bit of inheritance.
>>
>>>
>>> Some of the examples of the implementation that I could find used _Object_Iniitialize_information()
>>> to initialize the object type, then _Object_Allocate()/Free() allocate/de-allocate the object. Object_Id is used to control the object type. My confusion is, how do we use object IDs to refer to and control the allocated objects?
>>
>>
>> Every public API with an ID uses the score Object Handler to convert that ID into an instance to an object (base class) which is cast to an instance of the proper API type. An object has a name, ID, and a chain node. Any object can be put on lists. This is important because that's how the inactive set of each class of objects is managed. Various things are put on FIFO lists.
>>
>> The Chain handler which defines the Node structure and the Red-Black Tree are the foundation of many RTEMS data structures/algorithms.
>
>
> In the case of my project, I need to track and set the attributes of protected and shared stacks. The current implementation looks like this, maybe the APIs need to be in the public space, and if not, the stacks need to be tracked by score objects. I suppose the important question is,  what are the expectations as to how a mergeable implementation of this should look like?
>

Any resource managed by RTEMS should offer some API and mechanisms to
configure it. The current mmap/shm implementation missed that point
when I created it, and should be fixed.

>>
>>>
>>>
>>> I also have some confusion in the above-mentioned ticket, it says-
>>> 'The mmap_h handler should construct a mapping object. A destructor is currently missing. Maybe the mmap_h handler should use a flag to deal with construction and destruction.'
>>>  I am unclear as to how the mmap_h handler should precisely look like and where should it be defined?
>>
>>
>> I don't think this will be useful for your project. This is only used to provide a BSP specific mechanism to attach memory. This is primarily used in paravirtualized environments to allow the BSP to map memory shared with other address spaces. Without a hypervisor or host under RTEMS, this isn't going to be used. Although I think Gedare has at least one use case beyond this for it.
>>

There might be uses for it in libbsd, where there are portability
issues for applications that expect a functional mmap to exist. I
don't remember right off the top of my head though.

>> I think the stack allocator/deallocator hooks will be more useful.
>>
>>
>>>
>>> I would be grateful if you can provide some help in figuring this out.
>>>
>>> Regards,
>>> Utkarsh
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list