Author Topic: Floppy IRQs  (Read 5292 times)

0 Members and 1 Guest are viewing this topic.

Offline Warrior

  • supreme mac daddy of trolls
  • Hero Member
  • *****
  • Posts: 7503
  • One for a Dime two for a Quarter!
    • View Profile
Floppy IRQs
« on: December 19, 2005, 03:56:14 pm »
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
« Last Edit: December 19, 2005, 06:58:52 pm by MyndFyre[x86] »
One must ask oneself: "do I will trolling to become a universal law?" And then when one realizes "yes, I do will it to be such," one feels completely justified.
-- from Groundwork for the Metaphysics of Trolling

Offline Warrior

  • supreme mac daddy of trolls
  • Hero Member
  • *****
  • Posts: 7503
  • One for a Dime two for a Quarter!
    • View Profile
Re: Floppy IRQs
« Reply #1 on: December 19, 2005, 07:22:08 pm »
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.
One must ask oneself: "do I will trolling to become a universal law?" And then when one realizes "yes, I do will it to be such," one feels completely justified.
-- from Groundwork for the Metaphysics of Trolling

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: Floppy IRQs
« Reply #2 on: December 19, 2005, 07:38:48 pm »
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.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Joe

  • B&
  • x86
  • Hero Member
  • *****
  • Posts: 10319
  • In Soviet Russia, text read you!
    • View Profile
    • Github
Re: Floppy IRQs
« Reply #3 on: December 19, 2005, 08:11:03 pm »
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).
I'd personally do as Joe suggests

You might be right about that, Joe.


Offline Warrior

  • supreme mac daddy of trolls
  • Hero Member
  • *****
  • Posts: 7503
  • One for a Dime two for a Quarter!
    • View Profile
Re: Floppy IRQs
« Reply #4 on: December 19, 2005, 08:32:33 pm »
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.
One must ask oneself: "do I will trolling to become a universal law?" And then when one realizes "yes, I do will it to be such," one feels completely justified.
-- from Groundwork for the Metaphysics of Trolling

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: Floppy IRQs
« Reply #5 on: December 20, 2005, 02:01:48 pm »
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?
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Warrior

  • supreme mac daddy of trolls
  • Hero Member
  • *****
  • Posts: 7503
  • One for a Dime two for a Quarter!
    • View Profile
Re: Floppy IRQs
« Reply #6 on: December 20, 2005, 05:24:15 pm »
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..
One must ask oneself: "do I will trolling to become a universal law?" And then when one realizes "yes, I do will it to be such," one feels completely justified.
-- from Groundwork for the Metaphysics of Trolling

Offline Warrior

  • supreme mac daddy of trolls
  • Hero Member
  • *****
  • Posts: 7503
  • One for a Dime two for a Quarter!
    • View Profile
Re: Floppy IRQs
« Reply #7 on: December 20, 2005, 05:28:13 pm »
Additonally I found this, I might check it out
One must ask oneself: "do I will trolling to become a universal law?" And then when one realizes "yes, I do will it to be such," one feels completely justified.
-- from Groundwork for the Metaphysics of Trolling