[ptxdist] [PATCH 1/2] doc/welcome.rst: fix spelling

[ptxdist] [PATCH 1/2] doc/welcome.rst: fix spelling

[Felicitas Jung]

Signed-off-by: Felicitas Jung <f.jung@pengutronix.de>
---
 doc/welcome.rst | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/doc/welcome.rst b/doc/welcome.rst
index 58d3a4146..a0a360263 100644
--- a/doc/welcome.rst
+++ b/doc/welcome.rst
@@ -4,7 +4,7 @@ Welcome to the Embedded World
 First Steps in the Embedded World
 ---------------------------------
 
-Once upon in time, programming embedded systems was easy: all a
+Once upon a time, programming embedded systems was easy: all a
 developer needed when he wanted to start a new product was a good
 toolchain, consisting of
 
@@ -24,7 +24,7 @@ number of GPIO pins, UARTs and memory resources.
 
 Things have changed. Hardware manufacturers have weakened the border
 between deeply embedded microcontrollers – headless devices with just a
-few pins and very limited computing power – and full blown
+few pins and very limited computing power – and full-blown
 microprocessors. System structures became much more complicated: where
 our good old controllers have had just some interrupts with some small
 interrupt service routines, we today need complicated generic interrupt
@@ -32,7 +32,7 @@ infrastructures, suitable for generic software frameworks. Where we’ve
 had some linearly mapped flash ROM and some data RAM we today have
 multi-stage-pipeline architectures, memory management units, virtual
 address spaces, on-chip-memory, caches and other complicated units,
-which is not exactly what the embedded system developer wants program
+which is not exactly what the embedded system developer wants to program
 every other day.
 
 Entering embedded operating systems. Although there are still some
@@ -41,22 +41,22 @@ programmed the good old non-operating-system way with reasonable effort,
 it in fact is becoming more and more difficult. On the other hand,
 legacy I/O interfaces like RS232 are increasingly often replaced by
 modern plug-and-play aware communication channels: USB, FireWire
-(IEEE1394), Ethernet & friends are more and more directly being
+(IEEE1394), Ethernet & friends are more and more directly
 integrated into today’s microcontroller hardware. Whereas some of these
 interfaces can “somehow” be handled the old controller-style way of
 writing software, the developer following this way will not be able to
 address the security and performance issues which come up with the
 modern network accessible devices.
 
-During the last years, more and more of the small-scale companies which
+During the last few years, more and more of the small-scale companies which
 developed little embedded operating systems have been pushed out of the
-market. Nearly no small company is able to support all the different
+market. Nearly no small company is able to support all different
 interfaces, communication stacks, development tools and security issues
 out there. New interfaces and -variants (like USB On-the-Go) are
 developed faster than operating system developers can supply the
 software for them. The result is a consolidation of the market: today we
 see that, besides niche products, probably only the largest commercial
-embedded operating system suppliers will survive that development.
+embedded operating system suppliers will survive this development.
 
 Only the largest commercial...? There is one exception: when the same
 situation came up in the “mainstream” computer market at the beginning
@@ -83,11 +83,11 @@ Studies have shown that more than 70% of the embedded developers are not
 satisfied with a black-box operating system: they want to adapt it to
 their needs, to their special hardware situation (which most times is
 Just Different than anything available). Embedded projects are even more
-variegated than desktop- or server projects, due to the fact that there
-exist so many different embedded processors with lots of peripherals out
+variegated than desktop- or server projects, due to the fact that so many 
+different embedded processors with lots of peripherals exist out
 there.
 
-Linux has evolved from an i386 only operating system to a kernel running
+Linux has evolved from an i386-only operating system to a kernel running
 on nearly every modern 32 bit processor available today: x86, PowerPC,
 ARM, MIPS, m68k, cris, Super-H etc. The kernel supplies a hardware
 abstraction layer which lets our brave embedded developer once again
@@ -97,7 +97,7 @@ like memory management.
 But Linux is only half of the story. Besides the kernel, a Linux based
 embedded system consists of a “userland”: a filesystem, containing all
 the small tools which form a small Unix system. Only the combination of
-the kernel and a Userland let’s the developer run “normal” processes on
+the kernel and a Userland lets the developer run “normal” processes on
 his x86 development machine as well as on his embedded target.
 
 Linux = Embedded Linux
@@ -107,16 +107,16 @@ Whereas the mainstream developers were always able to use normal Linux
 distributions like SuSE, RedHat, Mandrake or Debian as a base for their
 applications, things are different for embedded systems.
 
-Due to the restricted resources these systems normally have,
+Due to the restricted resources of these systems,
 distributions have to be small and should only contain those things that
 are needed for the application. Today’s mainstream distributions cannot
 be installed in less than 100 MiB without major loss of functionality.
-Even Debian, probably today the most customizable mainstream
+Even Debian, probably today's most customizable mainstream
 distribution, cannot be shrunk below this mark without for example
 losing the packet management, which is an essential feature of using a
 distribution at all.
 
-- Additionally, source code for industrial systems has to be
+Additionally, source code for industrial systems has to be
 
 - auditable and
 
-- 
2.20.1


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

[ptxdist] [PATCH 2/2] readme: fix spelling

[Felicitas Jung]

Signed-off-by: Felicitas Jung <f.jung@pengutronix.de>
---
 README | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 54e64343d..60ac8b152 100644
--- a/README
+++ b/README
@@ -18,7 +18,7 @@ to build everything and
 
 to install it. When you start using PTXdist, make sure your $PATH
 environment variable points to <installpath>/bin, because that's where
-the ptxdist frontend program is being installed to.
+the PTXdist frontend program is being installed to.
 
 For developers who want to work with git versions of PTXdist it is only
 necessary to run "./autogen.sh && ./configure && make" and set the PATH
@@ -39,7 +39,7 @@ and you'll find a root tree in ./platform-<name>/root/, and disk images
 in ./platform-<name>/images/. Voilà.
 
 All magic necessary to do these things in a cross enviroment are written
-into "recipies", living in rules/*.make, and config menues in
+into "recipes", living in rules/*.make, and config menues in
 rules/*.in.
 
 Documentation
-- 
2.20.1


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 2/2] readme: fix spelling

[Roland Hieber]

For both patches:
Reviewed-by: Roland Hieber <rhi@pengutronix.de>

On Mon, Apr 06, 2020 at 02:02:27PM +0200, Felicitas Jung wrote:
> Signed-off-by: Felicitas Jung <f.jung@pengutronix.de>
> ---
>  README | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/README b/README
> index 54e64343d..60ac8b152 100644
> --- a/README
> +++ b/README
> @@ -18,7 +18,7 @@ to build everything and
>  
>  to install it. When you start using PTXdist, make sure your $PATH
>  environment variable points to <installpath>/bin, because that's where
> -the ptxdist frontend program is being installed to.
> +the PTXdist frontend program is being installed to.
>  
>  For developers who want to work with git versions of PTXdist it is only
>  necessary to run "./autogen.sh && ./configure && make" and set the PATH
> @@ -39,7 +39,7 @@ and you'll find a root tree in ./platform-<name>/root/, and disk images
>  in ./platform-<name>/images/. Voilà.
>  
>  All magic necessary to do these things in a cross enviroment are written
> -into "recipies", living in rules/*.make, and config menues in
> +into "recipes", living in rules/*.make, and config menues in
>  rules/*.in.
>  
>  Documentation
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de

-- 
Roland Hieber, Pengutronix e.K.          | r.hieber@pengutronix.de     |
Steuerwalder Str. 21                     | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686         | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [PATCH 2/2] readme: fix spelling

[Michael Olbrich]

On Mon, Apr 06, 2020 at 02:44:31PM +0200, Roland Hieber wrote:
> For both patches:

Hmmm, how do I get my tooling to parse this?

> Reviewed-by: Roland Hieber <rhi@pengutronix.de>

Thanks,
Michael

> On Mon, Apr 06, 2020 at 02:02:27PM +0200, Felicitas Jung wrote:
> > Signed-off-by: Felicitas Jung <f.jung@pengutronix.de>
> > ---
> >  README | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/README b/README
> > index 54e64343d..60ac8b152 100644
> > --- a/README
> > +++ b/README
> > @@ -18,7 +18,7 @@ to build everything and
> >  
> >  to install it. When you start using PTXdist, make sure your $PATH
> >  environment variable points to <installpath>/bin, because that's where
> > -the ptxdist frontend program is being installed to.
> > +the PTXdist frontend program is being installed to.
> >  
> >  For developers who want to work with git versions of PTXdist it is only
> >  necessary to run "./autogen.sh && ./configure && make" and set the PATH
> > @@ -39,7 +39,7 @@ and you'll find a root tree in ./platform-<name>/root/, and disk images
> >  in ./platform-<name>/images/. Voilà.
> >  
> >  All magic necessary to do these things in a cross enviroment are written
> > -into "recipies", living in rules/*.make, and config menues in
> > +into "recipes", living in rules/*.make, and config menues in
> >  rules/*.in.
> >  
> >  Documentation
> > -- 
> > 2.20.1
> > 
> > 
> > _______________________________________________
> > ptxdist mailing list
> > ptxdist@pengutronix.de
> 
> -- 
> Roland Hieber, Pengutronix e.K.          | r.hieber@pengutronix.de     |
> Steuerwalder Str. 21                     | https://www.pengutronix.de/ |
> 31137 Hildesheim, Germany                | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686         | Fax:   +49-5121-206917-5555 |
> 
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [APPLIED] readme: fix spelling

[Michael Olbrich]

Thanks, applied as 0c2cfcb884157e734f0d2d763bbe64ab953580d7.

Michael

[sent from post-receive hook]

On Tue, 07 Apr 2020 09:31:29 +0200, Felicitas Jung <f.jung@pengutronix.de> wrote:
> Signed-off-by: Felicitas Jung <f.jung@pengutronix.de>
> Reviewed-by: Roland Hieber <rhi@pengutronix.de>
> Message-Id: <20200406120227.8669-2-f.jung@pengutronix.de>
> Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
> 
> diff --git a/README b/README
> index 54e64343d6cc..60ac8b152b8b 100644
> --- a/README
> +++ b/README
> @@ -18,7 +18,7 @@ to build everything and
>  
>  to install it. When you start using PTXdist, make sure your $PATH
>  environment variable points to <installpath>/bin, because that's where
> -the ptxdist frontend program is being installed to.
> +the PTXdist frontend program is being installed to.
>  
>  For developers who want to work with git versions of PTXdist it is only
>  necessary to run "./autogen.sh && ./configure && make" and set the PATH
> @@ -39,7 +39,7 @@ and you'll find a root tree in ./platform-<name>/root/, and disk images
>  in ./platform-<name>/images/. Voilà.
>  
>  All magic necessary to do these things in a cross enviroment are written
> -into "recipies", living in rules/*.make, and config menues in
> +into "recipes", living in rules/*.make, and config menues in
>  rules/*.in.
>  
>  Documentation

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] [APPLIED] readme: fix spelling

[Michael Olbrich]

Thanks, applied as c10fbdf1cdab3823c12af9f4f4fed9f824ed7123.

Michael

[sent from post-receive hook]

On Tue, 07 Apr 2020 09:31:28 +0200, Felicitas Jung <f.jung@pengutronix.de> wrote:
> Signed-off-by: Felicitas Jung <f.jung@pengutronix.de>
> Reviewed-by: Roland Hieber <rhi@pengutronix.de>
> Message-Id: <20200406120227.8669-1-f.jung@pengutronix.de>
> Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
> 
> diff --git a/doc/welcome.rst b/doc/welcome.rst
> index 58d3a4146909..a0a360263cd7 100644
> --- a/doc/welcome.rst
> +++ b/doc/welcome.rst
> @@ -4,7 +4,7 @@ Welcome to the Embedded World
>  First Steps in the Embedded World
>  ---------------------------------
>  
> -Once upon in time, programming embedded systems was easy: all a
> +Once upon a time, programming embedded systems was easy: all a
>  developer needed when he wanted to start a new product was a good
>  toolchain, consisting of
>  
> @@ -24,7 +24,7 @@ number of GPIO pins, UARTs and memory resources.
>  
>  Things have changed. Hardware manufacturers have weakened the border
>  between deeply embedded microcontrollers – headless devices with just a
> -few pins and very limited computing power – and full blown
> +few pins and very limited computing power – and full-blown
>  microprocessors. System structures became much more complicated: where
>  our good old controllers have had just some interrupts with some small
>  interrupt service routines, we today need complicated generic interrupt
> @@ -32,7 +32,7 @@ infrastructures, suitable for generic software frameworks. Where we’ve
>  had some linearly mapped flash ROM and some data RAM we today have
>  multi-stage-pipeline architectures, memory management units, virtual
>  address spaces, on-chip-memory, caches and other complicated units,
> -which is not exactly what the embedded system developer wants program
> +which is not exactly what the embedded system developer wants to program
>  every other day.
>  
>  Entering embedded operating systems. Although there are still some
> @@ -41,22 +41,22 @@ programmed the good old non-operating-system way with reasonable effort,
>  it in fact is becoming more and more difficult. On the other hand,
>  legacy I/O interfaces like RS232 are increasingly often replaced by
>  modern plug-and-play aware communication channels: USB, FireWire
> -(IEEE1394), Ethernet & friends are more and more directly being
> +(IEEE1394), Ethernet & friends are more and more directly
>  integrated into today’s microcontroller hardware. Whereas some of these
>  interfaces can “somehow” be handled the old controller-style way of
>  writing software, the developer following this way will not be able to
>  address the security and performance issues which come up with the
>  modern network accessible devices.
>  
> -During the last years, more and more of the small-scale companies which
> +During the last few years, more and more of the small-scale companies which
>  developed little embedded operating systems have been pushed out of the
> -market. Nearly no small company is able to support all the different
> +market. Nearly no small company is able to support all different
>  interfaces, communication stacks, development tools and security issues
>  out there. New interfaces and -variants (like USB On-the-Go) are
>  developed faster than operating system developers can supply the
>  software for them. The result is a consolidation of the market: today we
>  see that, besides niche products, probably only the largest commercial
> -embedded operating system suppliers will survive that development.
> +embedded operating system suppliers will survive this development.
>  
>  Only the largest commercial...? There is one exception: when the same
>  situation came up in the “mainstream” computer market at the beginning
> @@ -83,11 +83,11 @@ Studies have shown that more than 70% of the embedded developers are not
>  satisfied with a black-box operating system: they want to adapt it to
>  their needs, to their special hardware situation (which most times is
>  Just Different than anything available). Embedded projects are even more
> -variegated than desktop- or server projects, due to the fact that there
> -exist so many different embedded processors with lots of peripherals out
> +variegated than desktop- or server projects, due to the fact that so many 
> +different embedded processors with lots of peripherals exist out
>  there.
>  
> -Linux has evolved from an i386 only operating system to a kernel running
> +Linux has evolved from an i386-only operating system to a kernel running
>  on nearly every modern 32 bit processor available today: x86, PowerPC,
>  ARM, MIPS, m68k, cris, Super-H etc. The kernel supplies a hardware
>  abstraction layer which lets our brave embedded developer once again
> @@ -97,7 +97,7 @@ like memory management.
>  But Linux is only half of the story. Besides the kernel, a Linux based
>  embedded system consists of a “userland”: a filesystem, containing all
>  the small tools which form a small Unix system. Only the combination of
> -the kernel and a Userland let’s the developer run “normal” processes on
> +the kernel and a Userland lets the developer run “normal” processes on
>  his x86 development machine as well as on his embedded target.
>  
>  Linux = Embedded Linux
> @@ -107,16 +107,16 @@ Whereas the mainstream developers were always able to use normal Linux
>  distributions like SuSE, RedHat, Mandrake or Debian as a base for their
>  applications, things are different for embedded systems.
>  
> -Due to the restricted resources these systems normally have,
> +Due to the restricted resources of these systems,
>  distributions have to be small and should only contain those things that
>  are needed for the application. Today’s mainstream distributions cannot
>  be installed in less than 100 MiB without major loss of functionality.
> -Even Debian, probably today the most customizable mainstream
> +Even Debian, probably today's most customizable mainstream
>  distribution, cannot be shrunk below this mark without for example
>  losing the packet management, which is an essential feature of using a
>  distribution at all.
>  
> -- Additionally, source code for industrial systems has to be
> +Additionally, source code for industrial systems has to be
>  
>  - auditable and
>  

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de