On Mon, Jun 15, 2020 at 11:29 AM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: > > > > > 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. >>> >>> 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@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
