2 * \file apidoc_mainpage.h
3 * \brief API Documentation Home Page
4 * \author John Hodge (thePowersGang)
8 * \mainpage Acess 2 Kernel API Documentation
10 * \section intro Introduction
11 * These documents attempt to describe the standard Acess 2 (and hopefully
12 * future versions) Kernel mode API.
13 * The documentation covers filesystem drivers, binary formats and the
14 * various device driver interface standards.
17 * The core of Acess is the VFS, or Virtual File System. The VFS abstracts
18 * away from the user the differences between different filesystems,
19 * network protocols and types of hardware.
20 * The core of the VFS is the concept of a VFS Node (represented by the
21 * ::tVFS_Node type). A node defines a file (either a normal file, directory
22 * or some device abstraction), it's attributes (size, flags, timestamps)
23 * and the functions used to access and modify it.
25 * \subsection filesystems Filesystem Drivers
26 * Acess filesystems register themselves with the VFS by calling
27 * ::VFS_AddDriver with a ::tVFS_Driver structure that defines the driver's
28 * name, flags and mount function.
29 * Filesystem drivers take the
31 * \section binfmt Binary Formats
34 * \section drivers Device Drivers
35 * All Acess2 device drivers communicate with user-level (and other parts
36 * of the greater kernel) via the VFS. They register themselves in a similar
37 * way to how filesystem drivers do, however instead of registering with
38 * the VFS core, they register with a special filesystem driver called the
39 * DevFS (fs_devfs.h). DevFS exports the ::DevFS_AddDevice function that
40 * takes a ::tDevFS_Driver structure as an agument that defines the
41 * driver's name and the VFS node of it's root. This root is used to
42 * provide the user access to the driver's function via IOCtl calls and
43 * by Read/Write calls. Drivers are also able to expose a readonly buffer
44 * by using ProcDev, usually to provide state information (such as usage
45 * statistics and other misc information)
47 * The device driver interfaces are all based on the core specifcation
48 * in tpl_drv_common.h (Common Device Driver definitions).
49 * The following subsections define the various specific types of driver
50 * interfaces. These definitions only define the bare minimum of what the
51 * driver must implement, if the driver author so wants to, they can add
52 * IOCtl calls and/or files (where allowed by the type specifcation) to
53 * their device's VFS layout.
55 * \subsection drv_video Video Devices
56 * Video drivers are based on a framebuffer model (unless in 3D mode,
57 * which is not yet fully standardised, so should be ignored).
58 * The driver will contain only one VFS node, that exposes the video
59 * framebuffer (this may not be the true framebuffer, to allow for double-buffering)
60 * to the user. See the full documentation in tpl_drv_video.h for the
61 * complete specifcation.