[PATCH 1/2] designprinciples.rst: Perform minor cleanups

[Claudius Heine]

On 2022-07-08 20:38, Tom Rini wrote:
> - Remove some missed wiki markup, and escape a "\n" correctly.
> - Use gender-neutral language to refer to the user, consistently.
> 
> Cc: Claudius Heine <ch at denx.de>
> Signed-off-by: Tom Rini <trini at konsulko.com>
> ---
>   doc/develop/designprinciples.rst | 28 ++++++++++++++--------------
>   1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/doc/develop/designprinciples.rst b/doc/develop/designprinciples.rst
> index 79694db77604..b6ceff1aa02b 100644
> --- a/doc/develop/designprinciples.rst
> +++ b/doc/develop/designprinciples.rst
> @@ -18,8 +18,8 @@ relatively small NOR flash memory, which is expensive
>   compared to the much larger NAND devices often used to store the
>   operating system and the application.
>   
> -At the moment, U-Boot supports boards with just 128 !KiB ROM or with
> -256 !KiB NOR flash. We should not easily ignore such configurations -
> +At the moment, U-Boot supports boards with just 128 KiB ROM or with
> +256 KiB NOR flash. We should not easily ignore such configurations -
>   they may be the exception in among all the other supported boards,
>   but if a design uses such a resource-constrained hardware setup it is
>   usually because costs are critical, i. e. because the number of
> @@ -28,15 +28,15 @@ millions...
>   
>   A usable and useful configuration of U-Boot, including a basic
>   interactive command interpreter, support for download over Ethernet
> -and the capability to program the flash shall fit in no more than 128 !KiB.
> +and the capability to program the flash shall fit in no more than 128 KiB.
>   
>   Keep it Fast
>   ^^^^^^^^^^^^
>   
>   The end user is not interested in running U-Boot. In most embedded
> -systems he is not even aware that U-Boot exists. The user wants to
> +systems they are not even aware that U-Boot exists. The user wants to
>   run some application code, and that as soon as possible after switching
> -on his device.
> +on their device.
>   
>   It is therefore essential that U-Boot is as fast as possible,
>   especially that it loads and boots the operating system as fast as possible.
> @@ -62,7 +62,7 @@ Keep it Simple
>   ^^^^^^^^^^^^^^
>   
>   U-Boot is a boot loader, but it is also a tool used for board
> -bring-up, for production testing, and for other activities
> +bring-up, for production testing, and for other activities.
>   
>   Keep it Portable
>   ^^^^^^^^^^^^^^^^
> @@ -95,13 +95,13 @@ Keep it Configurable
>   Section "Keep it Small" already explains about the size restrictions
>   for U-Boot on one side. On the other side, U-Boot is a powerful tool
>   with many, many extremely useful features. The maintainer or user of
> -each board will have to decide which features are important to him and
> -what shall be included with his specific board configuration to meet
> -his current requirements and restrictions.
> +each board will have to decide which features are important to them and
> +what shall be included with their specific board configuration to meet
> +their current requirements and restrictions.
>   
>   Please make sure that it is easy to add or remove features from a
>   board configuration, so everybody can make the best use of U-Boot on
> -his system.
> +their system.
>   
>   If a feature is not included, it should not have any residual code
>   bloating the build.
> @@ -124,7 +124,7 @@ debug is all the more important to many of us.
>   * All initialization steps shall print some "begin doing this" message before
>     they actually start, and some "done" message when they complete. For example,
>     RAM initialization and size detection may print a "RAM: " before they start,
> -  and "256 MB\n" when done.  The purpose of this is that you can always see
> +  and "256 MB\\n" when done.  The purpose of this is that you can always see
>     which initialization step was running if there should be any problem.  This
>     is important not only during software development, but also for the service
>     people dealing with broken hardware in the field.
> @@ -140,8 +140,8 @@ Please always keep in mind that there are at least three different
>   groups of users for U-Boot, with completely different expectations
>   and requirements:
>   
> -* The end user of an embedded device just wants to run some application; he
> -  does not even want to know that U-Boot exists and only rarely interacts with
> +* The end user of an embedded device just wants to run some application; they
> +  do not even want to know that U-Boot exists and only rarely interacts with
>     it (for example to perform a reset to factory default settings etc.)
>   * System designers and engineers working on the development of the application
>     and/or the operating system want a powerful tool that can boot from any boot
> @@ -151,7 +151,7 @@ and requirements:
>     U-Boot to be as simple as possible so porting it to and maintaining it on
>     their hardware is easy for them.
>   * Make it easy to test. Add debug code (but don't re-invent the wheel - use
> -  existing macros like debug() or debugX()).
> +  existing macros like debug()).
>   
>   Please always keep in mind that U-Boot tries to meet all these
>   different requirements.

Reviewed-by: Claudius Heine <ch at denx.de>