[PATCH rtems-libbsd] CONTRIBUTING: Sharpen priority development goals

[Christian Mauderer]

This patch tries to make the most important goals of LibBSD development
more clear based on the results of the discussion on the mailing list:

https://lists.rtems.org/pipermail/devel/2023-January/074164.html
---
 CONTRIBUTING.rst | 39 ++++++++++++++++++++++++++++++---------
 1 file changed, 30 insertions(+), 9 deletions(-)

diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
index 0b6fc7a0..31561f6a 100644
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -21,15 +21,36 @@ RTEMS specific support files, general guidelines on what modifications to the
 FreeBSD source are permitted, and some other topics.  For building the library,
 see the `README <README.rst>`_.
 
-Goals of the LibBSD activity are
-
-* provide functionality from FreeBSD to RTEMS,
-* ease updating to future FreeBSD versions,
-* ease tracking changes in FreeBSD code,
-* minimize manual changes in FreeBSD code.
-
-We will work to push our changes upstream to the FreeBSD Project and minimize
-changes required at each update point.
+Every change to LibBSD has to consider the following points in groups of
+descending priority:
+
+#. Real-time Impacts + Maintainability Loss
+   * LibBSD itself doesn't make any real time claims because it is basically
+     FreeBSD and they don't make any real time claims either.  But all
+     development in LibBSD must make sure that the real time ability of the
+     RTEMS core system or the application is not affected.
+   * It's utterly important that LibBSD is simple to maintain.  One of the most
+     important points for that is that upgrades to newer FreeBSD versions have
+     to be easy.
+#. Transparency Loss + Modularity Loss + Code/RAM Size Increase
+   * LibBSD code should be easy to read and easy to debug.  Changes should be
+     integrated in a way that are easy to understand.  Of course that's a
+     subjective goal.  As a general rule: If it adds lot's of extra code or even
+     more layers than already exist in FreeBSD, it's harder to understand.
+   * There are a number of methods used in LibBSD to make it modular.  If you
+     add new functionality, use one of the existing methods to allow enabling or
+     disabling your module.  For example make sure that the linker can remove
+     unused modules.  If that doesn't work for your feature, try to use the
+     buildsets to allow to switch a module on or off.
+   * A lot of different hardware uses LibBSD as network or USB stack or maybe in
+     the future even only for other subsystems.  Some of the targets have
+     hundreds of megabytes memory.  Others can only have a few megabytes (like
+     the ATSAMV71).  Make sure that changes don't increase the RAM / Flash size
+     of the default build so that it can't be used on the small targets.
+#. Performance Loss
+   * There are applications, that require (for example) a high network
+     throughput or a fast storage access.  Make sure to take that into account
+     if adding changes.
 
 What is in the Git Repository
 =============================
-- 
2.35.3