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

[Utkarsh Rai]

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.
>> <https://devel.rtems.org/ticket/3131>
>>
>> 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
<https://github.com/ur10/rtems/blob/test_branch/cpukit/score/src/stack_management.c>,
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?


>
>>
>> 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.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200615/dbbfa2ed/attachment.html>