Subversion Repositories shark

Rev

Rev 40 | Go to most recent revision | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
40 pj 1
- The vm86 reflection code contains a dirty hack: the vm86_exc1 function
2
	in vm86-exc.c hardcodes the int to be reflected...
3
	This should be fixed in some way!!!
4
    FIXED (and seems to be working very well...)
5
 
6
- Now, the registers structure should be fixed: move the flags field to the
7
	other side of the structure (adding the CS and EIP fields), so that
8
	we will not have to push flags and explicitly move it anymore...
9
    DONE
10
 
2 pj 11
- Fix problems with ASs and INTs (see kl/cxsw-1.s and xlib/exc.s)
12
	Done! At least it doesn't crash :)
13
	Must check in some way if the stack is correct or not...
40 pj 14
   I checked it, and it seems to be ok...
2 pj 15
 
16
- verify that only the needed .o files are linked (see -DPROFILE); provide
17
	a lightweight implementation of ``message'' (currently remapped on
18
	cprintf) that does not require linking libm
19
 
20
- profile and optimize the event management code
21
 
22
- rewrite cons.c isolating the parts making assumptions on memory spaces and
23
	improving efficency (window-based functions can be implemented
24
	separately)
25
 
26
- pentium timestamp conter code... Integrate it in timer code and event
27
	management
28
					Assigned to Gerardo
29
 
30
- provide some macro for int-based and call gate-based system calls
40 pj 31
    Done for INT: see examples/syscalls.c
2 pj 32
 
33
- begin to implement some serious code using OSLib:
34
	1) some simple multithreading executive based on cooperative and
35
		preemptive scheduling, message-based or based on shared
36
		memory and semaphores...
37
	2) some real small kernel, separating it from application code
38
	3) as 2), but with different address spaces for kernel and
39
		application
40
	...
41
 
42
- fix the eXtender in order to be fully multiboot compliant (no extension to
43
	the standard multiboot structure: we can use memory maps). Upgrade it
44
	to the latest version of the standard. Implement modules loading
45
  == Some work has been done... Now the eXtender can load MB compiant images
46
     and manages modules.
40 pj 47
  == Now everything is compatible with the latest MB standard (the loader
48
     name is used)
2 pj 49
     o Still to do: the memory map stuff & module parameters
40 pj 50
 
51
- what about fixing that _NOH4_ story?