File:  [DragonFly] / site / data / goals / Attic / iomodel.cgi
Revision 1.4: download - view: text, annotated - select for diffs
Mon Mar 1 03:39:08 2004 UTC (10 years, 1 month ago) by justin
Branches: MAIN
CVS tags: HEAD
Page titles below header are now centered by style and given a better
semantic markup.

Credit for this goes to:  Jon Parise <>

# $DragonFly: site/data/goals/iomodel.cgi,v 1.4 2004/03/01 03:39:08 justin Exp $

$TITLE(DragonFly - I/O Device Operations)
<H1>New I/O Device Model</H1>
I/O is considerably easier to fix then VFS owing to the fact that
most devices operate asynchronously already, despite having a semi-synchronous
API.  The I/O model being contemplated consists of three major pieces of work:
(1) I/O Data will be represented by ranges of VM Objects instead of ranges of
system or user addresses.  This allows I/O devices to operate entirely
independently of the originating user process.
(2) Device I/O will be handled through a port/messaging system (see 'messaging')
on the left.
(3) Device I/O will typically be serialized through one or more threads.
Each device will typically be managed by its own thread but certain high
performance devices might be managed by multiple threads (up to one per cpu).
Multithreaded devices would not necessarily compete for resources.  For
example, the TCP stack could be multithreaded with work split up by target
port number mod N, and thus run on multiple threads (and thus multiple cpus)
without contention.
As part of this work I/O messages will utilize a flat 64 bit byte-offset
rather than block numbers.
Note that device messages can be acted upon synchronously by the device.
Do not make the mistake of assuming that messages are unconditionally
serialized to the device thread because they aren't.  See the messaging
section on the left for more information.
It should also be noted that the device interface is being designed with
the flexibility to allow devices to operate as user processes rather then
as kernel-only threads.  Though we probably will not achieve this capability
for some time, the intention is to eventually be able to do it.  There are
innumerable advantages to being able to transparently pull things like 
virtual block devices and even whole filesystems into userspace.