Return to iomodel.cgi CVS log

Up to [DragonFly] / site / data / goals

Major Website Overhaul, Part 2 and 3: with regard to standards, target
code generation and general safety, I have also done other general
cleanups.

  * Make the website fully XHTML Transitional compliant.

  * Mop up and remove all invalid HTML tag combinations, and fix
    content structure.

  * Make use of tables for the Docs page, for presenting the
    documentation.  While I am at it, rearrange them by date.

  * Fix $TITLE() for a couple of pages.

  * Internal page headings, i.e. subheadings should use <h2>.

  * Turn *ALL* tags into lowercase, because UPPERCASE tags are
    not compliant on standards (XHTML to be precise).

  * Fix paragraphs, spelling errors, invalid lists and the
    whole nine yards.

  * Correct document layout for text-only and `for print'
    web clients.

  * While I am at it, make the various functions use const
    pointers.

Tested on:        Firebird (firefox, whatever...), Links, IE5+6, Opera
Reviewed by:      #dragonflybsd IRC channel on EFnet (joerg, eirikn)
Discussed with:   Justin Sherril

    1: #!/usr/local/www/cgi-bin/tablecg
    2: #
    3: # $DragonFly: site/data/goals/iomodel.cgi,v 1.5 2004/03/06 14:39:08 hmp Exp $
    4: 
    5: $TITLE(DragonFly - I/O Device Operations)
    6: 
    7: <h1>New I/O Device Model</h1>
    8: <p>
    9: I/O is considerably easier to fix then VFS owing to the fact that
   10: most devices operate asynchronously already, despite having a semi-synchronous
   11: API.  The I/O model being contemplated consists of three major pieces of work:</p>
   12: 
   13: <ol>
   14: <li>I/O Data will be represented by ranges of VM Objects instead of ranges of
   15: system or user addresses.  This allows I/O devices to operate entirely
   16: independently of the originating user process.</li>
   17: 
   18: <li>Device I/O will be handled through a port/messaging system (see 'messaging')
   19: on the left.</li>
   20: 
   21: <li>Device I/O will typically be serialized through one or more threads.
   22: Each device will typically be managed by its own thread but certain high
   23: performance devices might be managed by multiple threads (up to one per cpu).
   24: Multithreaded devices would not necessarily compete for resources.  For
   25: example, the TCP stack could be multithreaded with work split up by target
   26: port number mod N, and thus run on multiple threads (and thus multiple cpus)
   27: without contention.</li>
   28: </ol>
   29: 
   30: <p>
   31: As part of this work I/O messages will utilize a flat 64 bit byte-offset
   32: rather than block numbers.</p>
   33: <p>
   34: Note that device messages can be acted upon synchronously by the device.
   35: Do not make the mistake of assuming that messages are unconditionally
   36: serialized to the device thread because they aren't.  See the messaging
   37: section on the left for more information.</p>
   38: <p>
   39: It should also be noted that the device interface is being designed with
   40: the flexibility to allow devices to operate as user processes rather then
   41: as kernel-only threads.  Though we probably will not achieve this capability
   42: for some time, the intention is to eventually be able to do it.  There are
   43: innumerable advantages to being able to transparently pull things like 
   44: virtual block devices and even whole filesystems into userspace.</p>