OSDev.org

Hi. I will start to write my multitasking system. I need your suggestions.

First: which is good for starting and future of os;

1. Software Task Switching
2. Hardware Task Switching

Thanks.

Well they dropped hardware switching in newer processors, so I'd personally advise you to go for software switching so you don't have to rewrite it later.

From experience, I started off with hw tasks, i now do software tasks. Pros/cons:

Hardware:
+ on-cpu storing and loading of registers and segments
+ single instruction task switches
+ OS only needs to tell which task to run
+ only 16 bits needed to identify a task
- one GDT entry per task minimum
- if paging, the address space must be aware of each task in order to be able to switch to them (that means using a mediator or having all task segments in all address spaces)
- slower than software
- hardware taskswitching does not exist in longmode (unlike what the previous poster said, newer processors DO support them - they actually must - just not in 64-bit mode)

Software:
+ You can choose what to save and/or modify, instead of forced to a fixed set
+ Threads are not limited to the GDT size
+ Fast
+ You can keep task info in its own address space
- SW Scheduler code seems to be the most error-prone code around
- TSS segment is constant, which either needs you to reload parts of it, keep it all the same, or use paging tricks

Basically, Hardware is easier but rather limited and restrictive, Software needs quite a bit more work, but generally for better results.

And unless you like kernel rewrites you'll have to stick with the approach of your choice. Both are well usable, just pick the one that fits your os design best.

Wikihas a more detailed briefing on the pros and cons.

Well yeah, I was meaning if you use the new stuff then hardware switching isn't supported. Obviously they maintain backward compatibility so if you don't use the new stuff then you're effectively on an older processor which would support it.

My explaination made sense before I wrote it

Before starting with multitasking, I'd also make sure you have a failsafe interrupt handler working...

Candamir

hmm. The next, which is good for starting and future of os;

1. Segmentation
2. Paging

Thanks.

A good os:
3. Both

x86 architecture forces you to define and use segment registers, but normally we just make then 4Gbs big. That doesnt mean you can use them to their full capacity (keeping code and data truly apart and that sort of things). Things like VBE need full segmentation support, and if you want to support 16-bit windows apps you'll have to add extra segments as well. (i believe longmode has an different set of segments as well)

Paging is used very widely, including all commercial os's nowadays. Implementing address spaces is very difficult to do securely without it.

Given, most os's have the tendency to do more in the paging area than the segmentation area.

For starters:
4. None of the above
no paging, flat address space, no security to wonder about, no fuzz

Combuster wrote:(i believe longmode has an different set of segments as well)

x86-64 longmode "has no segments"

(habbit pauses for the sound of thousands of "false!!"s)

ok, ok, it DOES have segments. but they are, at best, residual:

• CS must point to a correct *DT code segment descriptor with the right flags for 64-bit long mode (D=0, L=1, IIRC). any other info (base, limit, permissions, etc) are ignored
• DS, ES and SS are mostly ignored: they just have to point to valid *DT data/stack segment descriptors, but everything else is ignored and they are assumed to span the entire linear address space
• FS and GS are a special case: they work like DS, ES and SS except for their base, which IS taken into account. That is, a FS with base=0x0000C000 WILL access that location when used such as in %fs:0. However, limits and permissions ARE IGNORED, as is granularity: try to put a byte-granular segment limit of 0x7F and you will still be able to acess %fs:0x80

Habbit wrote: (habbit pauses for the sound of thousands of "false!!"s)

Rudimentary.

[*]CS must point to a correct *DT code segment descriptor with the right flags for 64-bit long mode (D=0, L=1, IIRC). any other info (base, limit, permissions, etc) are ignored

D, L, P, CPL are used iirc. Can't find the purple book, so I can't tell you definitively.

[*]DS, ES and SS are mostly ignored: they just have to point to valid *DT data/stack segment descriptors, but everything else is ignored and they are assumed to span the entire linear address space

Actually, AMD has created nice images of all bits that are ignored in gray. All bits are gray except for the P-bit. So, you can make it either all ones or just that one bit a 1, it wouldn't care less. You could even point it at a code segment (since it ignores the segment type!).

[*]FS and GS are a special case: they work like DS, ES and SS except for their base, which IS taken into account. That is, a FS with base=0x0000C000 WILL access that location when used such as in %fs:0. However, limits and permissions ARE IGNORED, as is granularity: try to put a byte-granular segment limit of 0x7F and you will still be able to acess %fs:0x80
[/list]

Not entirely like DS, ES etc. Their base is used, and solely the base is used. If you point them at a segment they'll only use the base as a form of "second base-pointer". Intended use is for process or thread state. The kernel has its own GS base, which it can quickly recall with swapgs, so you can use that for the kernel-section of a process state (to store the registers, you don't use any register to swap the bases). IIRC no bits are used since they're not intended for use with a GDT or LDT but with MSR's that directly access their base registers.

Ok ok, here are the answers from the Book (d*mn you for forcing me to browse through my whole HD ).

Used for all segments: P bit.
Used for CS: D=0, L=1 (64-bit), DPL
Used for FS, GS: base address (but NO limit)

This is from the INTEL manual for "IA-32e", I don't have the AMD one, but I suppose there should be no major variations

PS1: where can i get the AMD manual? i've surfed throughout their site and i couldn't find it
PS2: maybe this should be added to the "What segments are about?" page in the wiki?

Habbit wrote: PS1: where can i get the AMD manual? i've surfed throughout their site and i couldn't find it

http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7044,00.html

JJ

Habbit wrote: Ok ok, here are the answers from the Book (d*mn you for forcing me to browse through my whole HD ).

Used for all segments: P bit.
Used for CS: D=0, L=1 (64-bit), DPL
Used for FS, GS: base address (but NO limit)

This is from the INTEL manual for "IA-32e", I don't have the AMD one, but I suppose there should be no major variations

PS1: where can i get the AMD manual? i've surfed throughout their site and i couldn't find it
PS2: maybe this should be added to the "What segments are about?" page in the wiki?

search for 24592, 24593, 24594, 26568 and 26569 on their web site. Those are the order no's for all the volumes. You really want part 2 and 3, 2 is system programming, 3 is generic opcodes (non-media and system).