/*
    ChibiOS/RT - Copyright (C) 2006,2007,2008,2009,2010 Giovanni Di Sirio.

    This file is part of ChibiOS/RT.

    ChibiOS/RT is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 3 of the License, or
    (at your option) any later version.

    ChibiOS/RT is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/

/**
 * @page goals Project Goals
 * <h2>Another RTOS?</h2>
 * The first question to be answered is: there was really the need for YET
 * ANOTHER RTOS?<br>
 * There are several reasons:
 * - The ChibiOS/RT ancestor was created more than 15 years ago and while it
 *   had far less features than the current product it was complete and
 *   functioning. ChibiOS/RT is just a new (and silly) name given to
 *   something created when there were not many free RTOSes around (actually
 *   none, at least none in my knowledge, there was no widespread Internet
 *   at that time).
 * - When, after a while, I needed a RTOS again, none of the existing FOSS
 *   projects met my expectations or my ideas of how a RTOS should be, not
 *   even close (see below). I decided that work on that old project was
 *   a better idea that contribute to, or fork, something else.
 * - I wanted another toy.
 * .
 * <h2>Why is it different?</h2>
 * Well, there are some design choices that should be explained and contribute
 * to make ChibiOS/RT a peculiar design. Nothing really new in itself but
 * the whole is interesting:
 *
 * <h3>Static design</h3>
 * Everything in the kernel is static, nowhere memory is allocated or freed,
 * there are three allocator subsystems but those are options and not part of
 * core OS. Safety is something you design in, not something you can add later.
 *
 * <h3>No tables, arrays or other fixed structures</h3>
 * The kernel has no internal tables, there is nothing that must be configured
 * at compile time or that can overflow at run time. No upper bounds, the
 * internal structures are all dynamic even if all the objects are statically
 * allocated.
 *
 * <h3>No error conditions and no error checks</h3>
 * All the system APIs have no error conditions, all the previous points are
 * finalized to this objective. Everything you can invoke in the kernel is
 * designed to not fail unless you pass garbage as parameters, stray pointers
 * as examples. The APIs are not slowed down by parameter checks,
 * parameter checks (and consistency checks) do exist but only when the
 * debug switch is activated.<br>
 * All the static core APIs always succeed if correct parameters are passed.
 * Exception to this are the optional allocators APIs that, of course,
 * can report memory exhausted.
 *
 * <h3>Very simple APIs</h3>
 * Each API should have the parameters you would expect for that function and
 * do just one thing with no options.
 *
 * <h3>Fast and compact</h3>
 * Note, first "fast" then "compact", the focus is on speed and execution
 * efficiency and then on code size. This does not mean that the OS is large,
 * the kernel size with all the subsystems activated weighs around <b>5.3KiB</b>
 * and can shrink down around to <b>1.2Kib</b> in a minimal configuration
 * (STM32, Cortex-M3). It would be possible to make something even smaller but:
 * -# It would be pointless, it is already @a really small.
 * -# I would not trade efficiency or features in order to save few bytes.
 * .
 * About the "fast" part, the kernel is able to start/exit more than
 * <b>220,000 threads per second</b> on a 72MHz STM32.
 * The Context Switch takes <b>1.41 microseconds</b> on the same STM32.
 *
 * <h3>Tests and metrics</h3>
 * I think it is nice to know how an OS is tested and how it performs before
 * committing to use it. Test results on all the supported platforms and
 * performance metrics are included in each ChibiOS/RT release. The test
 * code is released as well, all the included demos are capable of executing
 * the test suite and the OS benchmarks, see @ref testsuite.
 */