1 files changed, 0 insertions, 88 deletions
diff --git a/docs/src/goals.dox b/docs/src/goals.dox
deleted file mode 100644
index 6dc8f0034..000000000
--- a/docs/src/goals.dox
+++ /dev/null
@@ -1,88 +0,0 @@
-/*
-    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 than 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 over
- * <b>220,000 threads per second</b> on a 72MHz STM32.
- * The Context Switch takes <b>1.2 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.
- */