task_struct contains architecture independant process information.
thread_struct contains architecture dependant process information.
tss_struct is x86-specific, defined by the hardware.
> 1) I am having a difficult time understanding how tss_struct could be moved
> out of task_struct (per process basis, as one would expect) to a statically
> allocated array (per CPU basis, ???). How can these registers be saved
> across context switches, when there are only as many such structures as
> there are CPUs? I did not follow the explanation in UTLK.
The TSS (Task State Segment) structure is defined by the processor for
hardware task switching. Earlier versions of Linux on the x86 used one
TSS for each process and used hardware task switching. This effectively
limited the number of processes to about 500. We now have one TSS per
cpu, and do software task switching.
> 2) Why the multiple stack pointers and stack segments in tss_struct?
The x86 architecture has 4 priviledge levels (aka rings), with Linux
only using ring 3 (user) and ring 0 (kernel). When moving to a higher
privilege level (smaller numerically), a new stack pointer is loaded
fron the corresponding pointer in the TSS.
> 3) What is esp0 in thread_struct?
The kernel stack pointer for the current process. This is copied into
tss->esp0 when the process becomes current on a cpu.
> 4) What are the members suffixed with 'h' in tss_struct? I thought they were
> the segment shadow registers until I saw the member __ldth, because I didn't
> believe that ldt had a shadow register.
Segment registers are only 16 bits. the __*h values are the high 16
bits that are filler.
> 5) Is there a particular reason for the double underscore convention
> prefixing certain members?
To avoid any namespace collisions.
I suggest that you read the Intel documentation:
http://developer.intel.com/design/pentium4/manuals/245472.htm
In particular Chapter 6 Task Management
--Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/