<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 15, 2020 at 6:46 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 10, 2020 at 7:34 PM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</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"><div dir="ltr">Hello, <div>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 <a href="https://devel.rtems.org/ticket/3131" target="_blank">ticket.</a></div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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. <br><br>If you look at the Doxygen, you will see there is even a bit of inheritance.</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"><div dir="ltr"><div><br></div><div>Some of the examples of the implementation that I could find used _Object_Iniitialize_information()</div><div>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?</div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>The Chain handler which defines the Node structure and the Red-Black Tree are the foundation of many RTEMS data structures/algorithms.</div></div></div></blockquote><div><br></div><div>In the case of my project, I need to track and set the attributes of protected and shared stacks. The current implementation looks like <a href="https://github.com/ur10/rtems/blob/test_branch/cpukit/score/src/stack_management.c">this</a>, 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?</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"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I also have some confusion in the above-mentioned ticket, it says-</div><div>'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.'</div><div><i> </i>I am unclear as to how the mmap_h handler should precisely look like and where should it be defined?</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>I think the stack allocator/deallocator hooks will be more useful.  </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I would be grateful if you can provide some help in figuring this out.</div><div><br></div><div>Regards,</div><div>Utkarsh <br></div><div><br></div></div>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>
</blockquote></div></div>
</div>