On Mon, Jun 15, 2020 at 6:46 PM Joel Sherrill <j...@rtems.org> wrote:
> > > On Wed, Jun 10, 2020 at 7:34 PM Utkarsh Rai <utkarsh.ra...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
