1 files changed, 13 insertions, 14 deletions
diff --git a/docs/src/goals.dox b/docs/src/goals.dox
index d19c7d70a..3a2209f0c 100644
--- a/docs/src/goals.dox
+++ b/docs/src/goals.dox
@@ -38,7 +38,7 @@
  * .
  * <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 by itself but
+ * to make ChibiOS/RT a peculiar design. Nothing really new in itself but
  * the whole is interesting:
  *
  * <h3>Static design</h3>
@@ -46,11 +46,11 @@
  * there are two 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 or other fixed structures</h3>
+ * <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. Things that are not there cannot go wrong and take no space.
+ * allocated.
  *
  * <h3>No error conditions and no error checks</h3>
  * All the system APIs have no error conditions, all the previous points are
@@ -60,25 +60,25 @@
  * parameter checks (and consistency checks) do exists 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>
  * Every API should have the parameters you would expect for that function, no
  * more no less. Each API does a single thing with no options.
  *
  * <h3>Fast and compact</h3>
- * Note first "fast" then "compact", the focus is on speed and execution
- * efficiency rather than code size. This does not mean it is large, the OS
- * size with all the subsystems activated is well below 8KiB (32bit ARM code,
- * the least space efficient) and can shrink down below 2KiB. It would be
- * possible to make something smaller but:
+ * 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 is 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 sacrifice efficiency or features in order to save few bytes.
+ * -# 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>200,000 threads per second</b> on a 72MHz STM32 (Cortex-M3).
- * The Context Switch just takes <b>2.3 microseconds</b> on the same STM32.
- * The numbers are not pulled out of thin air, it is the output of the
- * included test suite.
+ * <b>200,000 threads per second</b> on a 72MHz STM32.
+ * The Context Switch takes <b>2.3 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
@@ -88,4 +88,3 @@
  * the test suite and the OS benchmarks.
  */
 /** @} */
- 
-\ No newline at end of file