union thread_union {

struct thread_info thread_info;

unsigned long stack[THREAD_SIZE/sizeof(long)];

In principle, individual architectures are, however, free to store whatever they like in the stack pointer if they signal this to the kernel by setting the pre-processor constant_have_thread_functions. In this case, they must provide their own implementations of task_thread_info and task_stack_page, which allows for obtaining the thread information and the kernel mode stack for a given task_struct instance. Additionally, they must implement the function setup_thread_stack that is called in dup_task_struct to create a destination for stack. Currently, only IA-64 and m68k do not rely on the default methods of the kernel.

On most architectures, one or two memory pages are used to hold an instance of thread_union. On IA-32, two pages are the default setting, and thus the available kernel stack size is slightly less than 8 KiB because part is occupied by the thread_info instance. Note, though, that the configuration option 4KSTACKS decreases the stack size to 4 KiB and thus to one page. This is advantageous if a large number of processes is running on the system because one page per process is saved. On the other hand, it can lead to problems with external drivers that often tend to be ''stack hogs,'' for example, use too much stack space. All central parts of the kernel that are part of the standard distribution have been designed to operate smoothly also with a stack size of 4 KiB, but problems can arise (and unfortunately have in the past) if binary-only drivers are required, which often have a tendency to clutter up the available stack space.

thread_info holds process data that needs to be accessed by the architecture-specific assembly language code. Although the structure is defined differently from processor to processor, its contents are similar to the following on most systems.

Continue reading here: Info

Was this article helpful?

0 0