OSDev.org

abless wrote: Well, if I use software task switching combined with *one* TSS, I don't have the portability argument anymore, do I?

Software stack-switching will work with any CPU, if this is what you wanna know. It is a bit more complicated to initialize user-level tasks, however, imho (because in order to start at USER_CS:USER_EIP, you must provide a stack that will reflect what would have happened if the user code has made a call to "reschedule" just before its entry point...)

I know software task-switching works on every CPU - but I *have* to use a TSS anyway - also when using software task-switching - so where's the portability here?

Any why can't I just set CS register point to USER CS and eip to USER eip? Where' the problem?

as the set up of the TSS will occur at kernel initialisation, it means your kernel initialisation (post-boot process, in some way) isn't portable-- and will probably never be as it also initializes GDT, IDT, etc.

The rest of your code (scheduler among others) will *be* portable.

As for the user code entry point, it will depend on how you implement the switch (it is possible to switch with only "pusha ; lss esp,[new-stack-identifier] ; popa ; ret" in a specific function), but whatever you choose, you will *not* be able to JMP user:code from kernel segment because USER.dpl > kernel.dpl

Hm, can't I just set up new tasks's ESP, CS, DS and so on and do an iret - like software task switching with kernel tasks?

yes, you can ... and that's what i did myself. But it is pretty bug-prone because you must build up a stack that will be used by all these pop's and ret's ... and the single forgotten bit will lead you to the VOID* land of #GPF ... muahahaaaah.

filling a TSS is much more intuitive. filling a stack must be done with care and a good tech manual at seeing distance ...

muahahaaaah.

*rofl*
You old pervert

filling a TSS is much more intuitive. filling a stack must be done with care and a good tech manual at seeing distance ...

I don't care - I won't use TSS, sorry

Pype.Clicker wrote:filling a TSS is much more intuitive. filling a stack must be done with care and a good tech manual at seeing distance ...

Are you saying you don't need the manual to fill out a TSS?

I'm definitely a software task switching man, for reasons I won't go into again unless anyone wants me to.

Perica Senjak wrote: Sorry, i got confused a bit ::); The GDT can hold up to 1024 Descriptors!

According to all other sources I've read (including one of Pype's comments too I believe), the GDT can hold 8192 entries since it size can be a maximum of 64 kb (=8192*8)... And I don't see anything that talk against this in that crasch course you mention...

..

Hard nut to crack...

What are your ressources, Perica?

-->

ad abless: I gonna try both of them: software taskswitching via stack changing, and hard ware task switching via tss. It is a nice thing to try out which of the two is to be understood better.

I understand, why software taskswitching is so error prone: you have to push and pop the registers in the right order to/from the stack of the process:

This I think it is to be done (I have studied the threads concerning this and also this text on kj's site) - just to get my own understanding of it:
1. push all registers on the stack of the process which is to be taken away from the cpu: the first item to be pushed to the stack is EIP -> the program counter.
2. switch over to the stack of the process to be run next:
3. Pop off the registers in the right order and at last leave EIP on the stack.
4. make ret or iret directly after this operation. the iret/ret takes the return adress from the stack.

stay safe folks

Perica Senjak wrote: So if you wanted to acess the first Descriptor, the index would be 0x0008 and if you wanted to acess the Next one the index is 0x0010. Because of this, i do not think it is possible to have more than 1024 Descriptors.

Then either stop thinking and read the manual... or drive your thought to their end: last selector will be 0xFFF8, which is 65528. As you have 8 byte per descriptor the last of selector is the 65528/8=8191th. period.

Hi people, you convinced me, I will (hopefully) call scheduler as you told me to do, however I will try not to implement software task switching for now, I am keen on hardware task switching. I will try to adopt it to code.(You may say who cares, and you are right... However I must say that I am still worried about not calling scheduler in its own context. Anyway. ;D) My question is, how does scheduler set tss entries? Does it have a pointer to gdt to alter them? I know that this might seem very obvious but I wanted to know how people implement them. Thanx...

..

with the whole 13 bit sets (which are shifted to the right -- so that
(selector&0xfff8) is the byte-offset in your table), you have the highest
possible selector (this is, the 8191th entry : 2^13 - 1 = 8191 = 0x1fff = 0xfff8 >> 3

Is there still something that confuse you ?? it seems obvious to me once you know how the different bits are placed.

..