OSDev.org

After much kicking from certain people who shall remain nameless, this morning I finally got around to writing the multitasking tutorial. It's part of the series at http://www.jamesmolloy.co.uk. Proofreaders would be most appreciated - I think some people here are waiting to see it anyway so I would appreciate it if people could point out mistakes here!

Cheers!

JamesM

http://www.jamesmolloy.co.uk/tutorial_h ... sking.html

Haven't read it yet, and already have my own multitasking system, but
/me loves JamesM

Edit: only mistake I saw was that in the bottom part of the tutorial, some html formatting got messed up and caused text to turn red.

Other than that, great tutorial

Cheers t0xic:

That formatting problem was an issue with the lexer when a string constant breaks multiple lines.

Fixx0red now!

Hi,

As always, it looks brilliant and very complete (all other multitasking tutorials I've seen are basically along the lines of "push all regs, switch esp, pop all regs"). I won't be following it as when I already have the design in mind for Caracal and have already implemented multitasking in several test kernels, but I wish this tutorial had been around when I was starting out!

Quick scan proof read reveals no errors other than a minor formatting error at the end (last screenshot seems to overshoot your text frame by a half). I'll have a more detailed look sometime.

Cheers,
Adam

Awesome!
However....
1) The link that points to the source code (download here) points to nothing...you get a 404 error.

2) The code still triple faults in Qemu after a bunch of tasks are started....

-JL

Looks cool, but the code to copy a physical frame looks... unsafe. It depends on the kernel being mapped in the same place in both the physical and virtual address spaces. Although not a problem for your tutorial, it will be problematic if someone wants to use that code in, say, a kernel running in the higher half.

Hi,

I think disabling paging to access physical memory is very slow.

yay! another tutorial.

when I get back to my house I will check it out deffinately.

Pe@cE

Hi guys, thanks for taking the time to go through it!

piranha wrote:Awesome!
2) The code still triple faults in Qemu after a bunch of tasks are started....
-JL

Yep, this will always happen as long as synchronisation primitives aren't implemented. It would be overkill to stick them in that tutorial (have you seen the length of it already?!) so just don't stress test it yet.

AlexExtreme wrote:Looks cool, but the code to copy a physical frame looks... unsafe. It depends on the kernel being mapped in the same place in both the physical and virtual address spaces. Although not a problem for your tutorial, it will be problematic if someone wants to use that code in, say, a kernel running in the higher half.

Alex, it's perfectly safe. As you say, it's tailored towards an identity mapped kernel (which is what we have in the tutorials). For a higher-half kernel, you *could* use the same technique, just with relative jumps.

jgraef wrote:I think disabling paging to access physical memory is very slow.

Hi. You're quite right. It is very slow. It involves a complete TLB refresh and also disables interrupts at one point, and don't even get me started on multiprocessing! but it's simple, and that's the aim of these tutorials. It's not to construct a foolproof, fantastic OS, it's to create one that does the job and is simple enough to be understood *fully*. Corner cases like this really do need consideration, but can be glossed over for the greater good in tutorials like this, IMHO.

As I say, the idea is to give an idea of how all the pieces fit together, not to do your work for you!

I'll fix the 404 now. Thanks for the comments and please keep 'em coming!

James

very nice, i read through the code a while back, and the documentation looks amazing.

one thing i would include is how to start and kill a task though, or atleast a howto described in text. Like the start_task() example in the thread from a month or so back.

Good point. I'll add that now. Normally (unix wise) execve is required to start tasks (fork()/execve() pair) but I'll add a threaded version in there too.

Theres one thing i dont undestand about it. You don't seem to save the general purpose registers anywhere... Is that not necessery? Or are they saved implicitly somewhere?

bucket_brigade wrote:Theres one thing i dont undestand about it. You don't seem to save the general purpose registers anywhere... Is that not necessery? Or are they saved implicitly somewhere?

Quote from article:
"
This relies on several things:

1. All the general purpose registers are already saved. This happens in the IRQ handler, so is automatic."

That's pretty much what i thought, funny how i missed that line. The whole readeip() stuff was pretty hard to wrap my head around, i think it needs a better explanation, maybe with some sort of graphic representation even