Subversion Repositories shark


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

- The vm86 reflection code contains a dirty hack: the vm86_exc1 function
        in vm86-exc.c hardcodes the int to be reflected...
        This should be fixed in some way!!!
    FIXED (and seems to be working very well...)

- Now, the registers structure should be fixed: move the flags field to the
        other side of the structure (adding the CS and EIP fields), so that
        we will not have to push flags and explicitly move it anymore...

- Fix problems with ASs and INTs (see kl/cxsw-1.s and xlib/exc.s)
        Done! At least it doesn't crash :)
        Must check in some way if the stack is correct or not...
   I checked it, and it seems to be ok...

- verify that only the needed .o files are linked (see -DPROFILE); provide
        a lightweight implementation of ``message'' (currently remapped on
        cprintf) that does not require linking libm

- profile and optimize the event management code

- rewrite cons.c isolating the parts making assumptions on memory spaces and
        improving efficency (window-based functions can be implemented

- pentium timestamp conter code... Integrate it in timer code and event
                                        Assigned to Gerardo

- provide some macro for int-based and call gate-based system calls
    Done for INT: see examples/syscalls.c

- begin to implement some serious code using OSLib:
        1) some simple multithreading executive based on cooperative and
                preemptive scheduling, message-based or based on shared
                memory and semaphores...
        2) some real small kernel, separating it from application code
        3) as 2), but with different address spaces for kernel and

- fix the eXtender in order to be fully multiboot compliant (no extension to
        the standard multiboot structure: we can use memory maps). Upgrade it
        to the latest version of the standard. Implement modules loading
  == Some work has been done... Now the eXtender can load MB compiant images
     and manages modules.
  == Now everything is compatible with the latest MB standard (the loader
     name is used)
     o Still to do: the memory map stuff & module parameters

- what about fixing that _NOH4_ story?