I'm currently designing the task-switching and memory management function of my kernel, and, having read the technical documentation, and a portion of the online tutorials, guides, et al, I get the impression that neither segmentation (beyond a flat memory model) nor hardware task-switching are particularly popular.
Thus, I was looking for advice on whether or not to use either of these technologies. As far as segmentation is concerned, I have a few ideas that would make full use of this (such as running multiple instances of the same code from the same code segment, but with different data segments, and using Ring 1 for hardware drivers), and was intending to write my own compiler anyway.
Ultimately, it seems that wider issues, like portability and future support, are more important factors than the actual technical viability. Therefore, what are your opinions? Should I look into these, and why/why not?
Thanks,
Keeper
A Matter of Opinion
-
DruG5t0r3
Re:A Matter of Opinion
Yeah apparently hardware task switching is getting slower and slower on new processors.
You do need to have one tss though in order to recover ss0 and esp0 when you switch back from user code (CPL > 0) to CPL0 or user code could literaly cause the kernel to crash because there is no stack space left.
Besides, you get much more control doing it software-wise, you can choose not to save unnecessary/unmodified registers etc.
You do need to have one tss though in order to recover ss0 and esp0 when you switch back from user code (CPL > 0) to CPL0 or user code could literaly cause the kernel to crash because there is no stack space left.
Besides, you get much more control doing it software-wise, you can choose not to save unnecessary/unmodified registers etc.
-
AR
Re:A Matter of Opinion
The middle rings (1,2) aren't used because paging only recognises supervisor (Ring0) and User (Ring3) [I don't remember which setting 1,2 come under]. Having the drivers in Ring1 still incurs a switching penalty, an interrupt would: User > Kernel > Driver > Kernel > User, each arrow represents a CS/DS/ES/SS switch. The pattern is pretty much identical to user-level drivers except without the additional TLB flush cost.
Segmentation is a potentially useful mechanism but if you depend on it then you won't be able to port your kernel to anything else, including x86-64.
Segmentation is a potentially useful mechanism but if you depend on it then you won't be able to port your kernel to anything else, including x86-64.
-
Crazed123
Re:A Matter of Opinion
Are there any replacements or similar mechanisms to rings 1 and 2?
-
JoeKayzA
Re:A Matter of Opinion
Most who use a flat memory model with only 2 privilege levels implement these 'intermediate' privilege levels on top of that - in software, actually.
I mean, you can perfectly have some tasks that run as 'user processes' and some tasks that are 'driver processes'. For the CPU, both of these are running in ring 3 and have distinct address spaces. For your OS kernel however (so, at a higher level of abstraction), the driver processes might have a higher priority, and direct access to the memory of the user processes too (the kernel can map it into the driver's address space on demand). You see, there are plenty of methods how to implement the lost hardware functionality in software.
cheers Joe
I mean, you can perfectly have some tasks that run as 'user processes' and some tasks that are 'driver processes'. For the CPU, both of these are running in ring 3 and have distinct address spaces. For your OS kernel however (so, at a higher level of abstraction), the driver processes might have a higher priority, and direct access to the memory of the user processes too (the kernel can map it into the driver's address space on demand). You see, there are plenty of methods how to implement the lost hardware functionality in software.
cheers Joe