- view: text
- select for diffs
Sat Mar 6 14:39:08 2004 UTC
(10 years, 10 months ago) by hmp
CVS tags: HEAD
Major Website Overhaul, Part 2 and 3: with regard to standards, target
code generation and general safety, I have also done other general
* Make the website fully XHTML Transitional compliant.
* Mop up and remove all invalid HTML tag combinations, and fix
* 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'
* While I am at it, make the various functions use const
Tested on: Firebird (firefox, whatever...), Links, IE5+6, Opera
Reviewed by: #dragonflybsd IRC channel on EFnet (joerg, eirikn)
Discussed with: Justin Sherril
3: # $DragonFly: site/data/goals/iomodel.cgi,v 1.5 2004/03/06 14:39:08 hmp Exp $
5: $TITLE(DragonFly - I/O Device Operations)
7: <h1>New I/O Device Model</h1>
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>
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>
18: <li>Device I/O will be handled through a port/messaging system (see 'messaging')
19: on the left.</li>
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>
31: As part of this work I/O messages will utilize a flat 64 bit byte-offset
32: rather than block numbers.</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>
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>