DWin RFC: TIO

DWin RFC: TIO
TIO is the most exciting part of DWE, and if nothing else comes to pass, TIO will still make DWin a force to reckon with. Long time users of any Unix variant know of the Everything is a File concept, one that has it's advantages and disadvantages. TIO takes this idea, and says that everything is a stream of data. And by everything, I really mean everything from files to sockets, from device drivers to pipes. TIO is simply a base class that all input and output derive from. It sets up a handshaking system, allows for data to be passed back and forth between streams and even allows for streams to pass their data automatically on to another stream. Let's look at an example of TIO that got us excited about this. Let's say we want to play an Ogg Vorbis file. Traditionally, you had to set up the sound output, setup the file input, set up the Vorbis decoder and sit in a loop that decodes and then sends the data to the sound output. TIO however, simplifies that. First we get the sound driver from the driver manager (more on that later), then create a Vorbis TIO object, then assign the file we want to play to a file TIO. Attach the Vorbis object to the sound driver, and then attach the file to the Vorbis player. At that instant, messages go back and forth between the three objects, negotiating the system, then starting it to go. If the Sound Driver is interrupt based, the entire process from there on out is automatic, no blocking required. If one so desires, a blocking status call can be called until the file is at the end. In the case that the sound driver is blocking, when the call comes back, the entire file will have been played. Oh, but what's the genius in that? That's easy, you can replace any one of the three parts with a similar TIO function. The sound driver could just as easily be a file object, meaning you write a raw PCM data from the Vorbis object to a file. Or you can replace the file object with a socket and the Vorbis object will be just as happy. Or even replace the Vorbis object with Flak or MP3. TIO is all about being modular. If two tasks are similar, they should be able to replace each other, and TIO hopes to accommodate that.

Managers are still in the planning phase as opposed to TIO, which has a working definition, but that is what this paper is to do: help define what different aspects of DWin do and how they work. Managers are directly related to TIO objects, in that Managers dispense TIO's. There is one major manager that is available everywhere on DWE, and that is the Device Manager (DM). This manager is in charge of allocating, dispensing and reclaiming TIO device access. So, let's say someone wants a sound TIO to play some audio, they would have to ask the DM for a sound TIO, the DM then asks any loaded audio managers that have happened to be loaded by an audio driver for a audio TIO. If no such manager exists, but the audio driver has given an audio TIO to the DM, the DM will check who has the TIO, if it is not owned or reclaimable because of defunk process or otherwise unused, the DM will return the first available TIO. If there is no available TIO, then the DM will generate a generic TIO that does nothing, and returns that one (maybe letting the caller know that it is a blank TIO).

TIO Interface

type
 TIOStatus = (Unsupported, Done, Success, Ready, Busy, Ignore);

 PTIO = ^TIO;
 TIO = object
  constructor create;
  procedure readblock(p: pointer; var len: cardinal); virtual;
  procedure writeblock(p: pointer; var len: cardinal); virtual;
  procedure read(var p: cardinal); virtual;
  procedure write(p: cardinal); virtual;
  procedure seek(p: cardinal); virtual;
  function pos: cardinal; virtual;
  function size: cardinal; virtual; {Amount of data available, in bytes}
  function reclen: cardinal; virtual; {Length of each "packet", in bytes}
  function attach(target: PTIO): boolean; virtual;
  function notify(s: PTIO): TIOStatus; virtual;
  function query(s: PTIO): TIOStatus; virtual;
  function status: TIOStatus; virtual;
  destructor destroy; virtual;
 end;

Manager Interface

 TManagerStatus = (Available, Empty);

 TManager = object
   function allocate: PTIO;
   function status: TManagerStatus;
 end;

DM inner workings

  PStringArray = ^stringArray;
  stringArray = array of string;

  TDrvManager = object
    function enum(devClass: string): PStringArray;
    function allocate(devClass, device: string): PTIO;
    procedure register(devClass, device: string; Sender: TManager);
    procedure register(devClass, device: string; var Sender: TIO);
    procedure unregister(Sender: TManager);
    procedure unregister(Sender: TIO);
    function addIRQ(num: word; entry: pointer; Sender: pointer): TIOStatus;
    function rmIRQ(num: word; Sender: pointer): TIOStatus;
    function allocDMA(num: word; Sender: pointer): TIOStatus;
    function deallocDMA(num: word; Sender: pointer): TIOStatus;
    function allocPort(num: word; Sender: pointer): TIOStatus;
    function deallocPort(num: word; Sender: pointer): TIOStatus;
    procedure PRNG(num: cardinal);
  end;

PRNG
All drivers have the opportunity (and we hope that they do) to participate in the Psudo-Random Number Generator. By calling the Device Manager.s PRNG procedure with some incoming data, it can help DWin.s Random capabilities by using I/O devices. For example, a keyboard driver might send the PRNG the keyboard scan and ASCII codes that it deals with every time. PRNG is a low latency function that just builds a seed, the actual random device uses this seed to produce the psudo-random numbers.

Note: This is an archived website. I built this between 2000 and 2004 and in some small way I feel that it has defined how I view my online presence. Although it's been years since I've updated, I have decided to keep it in its original glory and preserve it instead of replacing it with a blank page. Enjoy this glimpse into my younger self.