[PATCH 5/7] designprinciples.rst: Perform minor cleanups
xypron.glpk at gmx.de
Wed Jul 13 19:40:03 CEST 2022
On 7/11/22 19:14, 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>
> Cc: Heinrich Schuchardt <xypron.glpk at gmx.de>
> Signed-off-by: Tom Rini <trini at konsulko.com>
> Changes in v2:
> - None
> doc/develop/designprinciples.rst | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
> diff --git a/doc/develop/designprinciples.rst b/doc/develop/designprinciples.rst
> index 43aeb5dacf5f..e5e12dca79f5 100644
> --- a/doc/develop/designprinciples.rst
> +++ b/doc/develop/designprinciples.rst
> @@ -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
"The end user" is singular.
> 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.
> @@ -63,7 +63,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
> @@ -96,13 +96,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.
> @@ -126,7 +126,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.
> @@ -143,8 +143,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
Please, don't mix singular and plural.
> + 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
> @@ -157,7 +157,7 @@ and requirements:
> 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.
More information about the U-Boot