Return to iomodel.cgi CVS log

Up to [DragonFly] / site / data / goals

Page titles below header are now centered by style and given a better
semantic markup.

Credit for this goes to:  Jon Parise <jon@indelible.org>

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