Kernel/include/apidoc_mainpage.h

   1 /**
   2  * \file apidoc_mainpage.h
   3  * \brief API Documentation Home Page
   4  * \author John Hodge (thePowersGang)
   5  */
   6
   7 /**
   8  * \mainpage Acess 2 Kernel API Documentation
   9  *
  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.
  15  *
  16  * \section VFS
  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.
  24  *
  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
  30  *
  31  * \section binfmt Binary Formats
  32  * See binary.h
  33  *
  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)
  46  *
  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.
  54  *
  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.
  62  */