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