Floppy IRQs

[Warrior]

Yea if you look @ all the driver calls in Windows9x and ME they are almost (for block devices atleast) calls to Virtual8086 mode.
ME was Windows trying to cover up DOS. Christ it isn't that hard to write a floppy driver to use IO ports. I wrote one in like 2 weeks with like one PDF. Oh well.

One problem I did face however (and appearantly others are facing too) is for example with a floppy driver:

Uses the Floppy IRQ to read calls..ok? Good.

Now what to do if the task is switched while we wait for the Floppy IRQ? We return data to the wrong process. I think I'm going to have to implement a queue for operations in the kernel or something *sigh*
MyndFyre edit: changed the topic title after post was split

[Warrior]

Haha @ this being moved here, I just implemented a simple queue which waited for the task to be in queue before returning whatever data through the stream.

[MyndFyre]

IIRC (and this is described in detail in Windows Internals), the basic timeslice assigned to a process in Windows is called a quantum.  There are (IIRC) 31 priority levels in the Windows kernel, and I believe that the highest priority a user-mode process can have is 15.  There might be something like 3 levels for each API priority level (like Normal might be 10-12 or something like that), and each task gets a particular timeslice; when a task other than the one currently in-process gets a higher priority level, that task preempts the one currently in use.

Anyway, IIRC, when an I/O request is made, the process' priority is elevated by like 4 levels, so that when the process' quantum expires and the operating system looks for other processes at the higher (same as current process) priority, it doesn't find any.  The process priority decays over time as more quanta expire, and eventually it returns to its normal operating level.

This is an OK technical article about how quanta are used in scheduling and driver management.  Still, Windows Internals is one of the best books available on the subject of them.

[Joe]

If Windows does it like Linux does, the "nice" level goes from -15 to 15 (including 0), so yea, 31. The less "nice" you are, the less willing you are to share (processor time).

[Warrior]

That seems more efficient but a little too complicated. In my OS I do everything socket style currently.

ex.

OpenFile();
      ReadFile();
--- >CloseFile();

Opens a stream to the VFS (a work in progress) and begins to wait for a request to be made, when a request is made it sends the data back packet style and the application recieves it. Once the data is recieved (or sent out to the end zone of the application) the stream is instantly closed. They seem to be working fine.

For multithreading I have two "stacks"

Runnable processes and Waiting processes

Runnable holds processes that CAN run and are waiting in line for a turn the scheduler picks from this
Waiting processes are basically things that are blocking or frozen or paused or zombies (waiting to be killed)

Then the "idle" thread (really does way more) checks the waiting processes for messages of an operation completed and removes them from that stack and sets up the address space and puts them in the runnable stack.

While most of this is theory some of it has actually been implemented :p

Also something to think of is exposing part of the offscreen buffer to applications as an option to directly draw to (allocate maybe an empty spot in it depending on window placement or do some relocation on the GUI server side) since things like Media players and games need a pretty fast refresh rate, no overhaul from kernel syscalls and whatnot.

[MyndFyre]

That seems okay but like you would have problems with I/O.  Specifically, that you'd run into trouble when trying to switch out; if the I/O request is blocking, how will it let you switch out unless you have higher process priorities?

[Warrior]

Well when a blocking API is called it will add the process to the "Wait Queue" which will only stop the process from running after it's CURRENT time slice is done.

Example:

ProcessA calls: WaitForMessage()
ProcessA can continue to run until it's time slice reaches 0
ProcessA is suspended (Time slice up)
(Scheduling takes place)
ProcessB starts
ProcessB runs
ProcessA will be rescheduled when it's Blocking function returns
ProcessB ends
(Scheduling takes place, lalala)
ProcessA starts again (Only two processes in this example :p)
ProcessA runs

etc..

[Warrior]

Additonally I found this, I might check it out