3: # $DragonFly: site/data/goals/iomodel.cgi,v 1.4 2004/03/01 03:39:08 justin Exp $
5: $TITLE(DragonFly - I/O Device Operations)
6: <H1>New I/O Device Model</H1>
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:
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.
16: (2) Device I/O will be handled through a port/messaging system (see 'messaging')
17: on the left.
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.
27: As part of this work I/O messages will utilize a flat 64 bit byte-offset
28: rather than block numbers.
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.
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.