Shulou(Shulou.com)06/01 Report--

RT-Thread kernel object manager design ideas, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

RT-Tread kernel architecture

RT-Thread, the full name is Real Time-Thread, as its name implies, it is an embedded real-time multithreaded operating system, one of the basic properties is to support multitasking, allowing multiple tasks to run at the same time does not mean that the processor really executes multiple tasks at the same time. The kernel architecture is shown in the following figure:

RT-Thread kernel and its underlying structure

The functions of each part are not described here. What attracts me to the RT-Tread kernel:

The code is elegant, readable, very compact, code-like Linux style, active tailoring community, Chinese independent development, more and more excellent designs for users. For the idea of object-oriented design, it can be said that the excellent practice is mainly located in the Internet of things applications, a variety of components are rich, the integration is also very good.

So if you are a RTOS application or developer, it will be a pity if you don't read the kernel which is so excellent and easy to learn in depth. To understand the idea of RT-Thread object design, it is a very good starting point to start with the management of kernel object object.

What is RT-Thread kernel object management?

RT-Thread uses kernel object management system to access / manage all kernel objects. Kernel objects contain most of the facilities in the kernel. These kernel objects can be statically allocated static objects or dynamic objects allocated from the system memory heap. Through the design of this kernel object, RT-Thread does not depend on the specific memory allocation, and the flexibility of the system has been greatly improved.

RT-Thread kernel objects include: threads, semaphores, mutexes, events, mailboxes, message queues and timers, memory pools, device drivers, etc. The object container contains information about each type of kernel object, including object type, size, and so on. The object container assigns a linked list to each type of kernel object, and all kernel objects are linked to the linked list, as shown in figure RT-Thread 's kernel object container and linked list:

Kernel object Container and linked list of RT-Thread

Reference from: https://www.rt-thread.org/document/site/programming-manual/basic/basic/#_7

This centrally managed kernel object container costs little in terms of memory overhead, but it has a high degree of flexibility. From a design point of view, its code is also very conducive to expansion, adding new kernel object categories, and tailoring and adapting the corresponding kernel object functions.

What does the kernel object mainly do?

The main implementation code of the RT-Thread kernel object subsystem is object.c. This paper attempts to interpret its design idea from the whole to the part. From an external black box point of view, the object.c subsystem mainly implements these use case requirements as far as it is understood:

Therefore, the personal understanding of the kernel object manager is mainly to provide data management support for other kernel functional modules, which belongs to the underlying supporting functional components of the kernel, and takes into account the scalable and tailored requirements in terms of design.

How did it happen?

The main core data structures of the RT-Thread kernel object subsystem are as follows:

Where the rt_object_class_type enumeration defines the kernel object category:

Enum rt_object_class_type

{

RT_Object_Class_Null = 0, / * not used * /

RT_Object_Class_Thread, / * thread object * /

RT_Object_Class_Semaphore, / * semaphore object * /

RT_Object_Class_Mutex, / * mutex object * /

RT_Object_Class_Event, / * event object * /

RT_Object_Class_MailBox, / * mail box object * /

RT_Object_Class_MessageQueue, / * message queue * /

RT_Object_Class_MemHeap, / * memory heap * /

RT_Object_Class_MemPool, / * memory pool * /

RT_Object_Class_Device, / * device object * /

RT_Object_Class_Timer, / * timer object * /

RT_Object_Class_Module, / * module * /

RT_Object_Class_Unknown, / * unknown * /

RT_Object_Class_Static = 0x80 / * 8-bit type variable high position 1 represents a static object * /

}

On the other hand, rt_object_information abstracts the object type and adds a two-way linked list pointer data field rt_list_node, which links the kernel objects of the same category with the double-chain pointer. These kernel objects of the same category have the following possible characteristics:

It may be generated while the software is running, or it may be created at os initialization. Its storage type may be static or dynamic (the so-called dynamic type here does mean that the dynamically applied memory area on the kernel reactor is used to store the corresponding kernel objects). In memory space, its location is not contiguous.

In this way, the spatially discontinuous variables of these kernel objects are used to form a unified manageable, adding, deleting and retrievable logical structure by using linked lists.

The rt_object_container kernel container, which is essentially a kernel object index table, centrally manages the following information:

Enum rt_object_class_type type: kernel object category, category of entries recorded in each table rt_list_t object_list: list pointer data field of the header node of the linked list of each type of object rt_size_t object_size: the size of this type of individual

The corresponding linked list is selected and compiled by macros, and the key data in the kernel is cut and managed. As for the expansibility of the kernel itself, if we need to add new kernel functions, we can easily add new kernel object classes and add them to this kernel object container, using the common external interface to achieve unified management. without the need for additional interface design for the data management layer.

What external interfaces have been implemented?

With such an elegant data structure design, based on such a data structure design, it is easy to implement the external service interface of centralized management of kernel objects, so what are the main service interfaces?

Some of the main APIs implement the addition / deletion / retrieval of objects. Here we take the rt_object_init API as an example to briefly analyze its implementation:

Void rt_object_init (struct rt_object * object

Enum rt_object_class_type type

Const char * name)

{

Register rt_base_t temp

Struct rt_list_node * node = RT_NULL

Struct rt_object_information * information

# ifdef RT_USING_MODULE

Struct rt_dlmodule * module = dlmodule_self ()

# endif

/ * 1. Find out what object class this is in the container * /

Information = rt_object_get_information (type)

RT_ASSERT (information! = RT_NULL)

/ * check object type to avoid re-initialization * /

/ * enter the critical zone to protect * /

Rt_enter_critical ()

/ * try to find object * /

For (node = information- > object_list.next

Node! = & (information- > object_list)

Node = node- > next)

{

Struct rt_object * obj

Obj = rt_list_entry (node, struct rt_object, list)

If (obj) / * skip warning when disable debug * /

{

RT_ASSERT (obj! = object)

}

}

/ * leave the critical area * /

Rt_exit_critical ()

/ * initialize object parameters and set them to static tags * /

Object- > type = type | RT_Object_Class_Static

Rt_strncpy (object- > name, name, RT_NAME_MAX)

RT_OBJECT_HOOK_CALL (rt_object_attach_hook, (object))

/ * disable hardware interrupts * /

Temp = rt_hw_interrupt_disable ()

# ifdef RT_USING_MODULE

If (module)

{

Rt_list_insert_after (& (module- > object_list), & (object- > list))

Object- > module_id = (void *) module

}

Else

# endif

{

/ * the corresponding object branch chain is inserted into the container * /

Rt_list_insert_after (& (information- > object_list), & (object- > list))

}

/ * turn on hardware interrupt * /

Rt_hw_interrupt_enable (temp)

}

The main way to add / delete kernel objects is to use the kernel container to first retrieve the link header node, and then further do the basic operation of the two-way linked list. Here, we will not elaborate on how to operate the linked list. For the retrieval and query of kernel object-related data fields, there is a clear data structure, and the node linked list pointer can be retrieved, because the node linked list pointer has a definite relative position relationship with each data field of the corresponding kernel object. so retrieval is very easy to implement.

As for the dynamic kernel object, the difference lies in that the kernel object itself is applied dynamically. It should be noted here that the kernel heap is applied to the kernel heap, not the C heap. As for what the kernel heap is and why the kernel heap is designed, I have written an article to share it before. If you are interested, you can check it out.

What is the inheritance relationship between kernel objects?

The following interrelation graph is given on the RT-Thread pipe network:

RT-Thread kernel object inheritance relationship

If you do not look at the corresponding data structure, it may be difficult to understand why there is such a picture. Here are some of the kernel objects in the above figure to shake off their interrelationships:

Maybe some friends will ask why rt_object is not directly included in the rt_thread object, so why does rt_thread inherit from rt_object? If you take a closer look at the data field in the red box in rt_thread above, you will suddenly realize that even if it is not directly included, the content in the box in memory is the data content of rt_object, so you can easily access it by using pointer conversion. Why is this the case? I think it may be historical reasons? So the location of the first few data fields of the rt_thread structure cannot be changed. Here you may also ask why kernel objects related to ipc thread communication need to be pulled out of a separate parent structure. I think it should be that this class has some commonalities and some similar characteristics. This is also an embodiment of object design to extract commonness and then abstract encapsulation.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.