manuals: replace "rootfs" by "root filesystem"

Almost everyone understands "rootfs", but "root filesystem"
is real English.

(From yocto-docs rev: 3d610f15e5b6be3435e9e81e4498a676671e5b39)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/ref-manual/classes.rst

@@ -1362,9 +1362,9 @@ is set to 0.
 
 Only a single Initramfs bundle can be added to the FIT image created by
 ``kernel-fitimage`` and the Initramfs bundle in FIT is optional.
-In case of Initramfs, the kernel is configured to be bundled with the rootfs
+In case of Initramfs, the kernel is configured to be bundled with the root filesystem
 in the same binary (example: zImage-initramfs-:term:`MACHINE`.bin).
-When the kernel is copied to RAM and executed, it unpacks the Initramfs rootfs.
+When the kernel is copied to RAM and executed, it unpacks the Initramfs root filesystem.
 The Initramfs bundle can be enabled when :term:`INITRAMFS_IMAGE`
 is specified and that :term:`INITRAMFS_IMAGE_BUNDLE` is set to 1.
 The address where the Initramfs bundle is to be loaded by U-boot is specified
@@ -1712,13 +1712,13 @@ layers.
 ``overlayfs.bbclass``
 =======================
 
-It's often desired in Embedded System design to have a read-only rootfs.
+It's often desired in Embedded System design to have a read-only root filesystem.
 But a lot of different applications might want to have read-write access to
 some parts of a filesystem. It can be especially useful when your update mechanism
-overwrites the whole rootfs, but you may want your application data to be preserved
+overwrites the whole root filesystem, but you may want your application data to be preserved
 between updates. The :ref:`overlayfs <ref-classes-overlayfs>` class provides a way
 to achieve that by means of ``overlayfs`` and at the same time keeping the base
-rootfs read-only.
+root filesystem read-only.
 
 To use this class, set a mount point for a partition ``overlayfs`` is going to use as upper
 layer in your machine configuration. The underlying file system can be anything that

documentation/ref-manual/kickstart.rst

@@ -87,7 +87,7 @@ the ``part`` and ``partition`` commands:
 
    If you use ``--source rootfs``, Wic creates a partition as large as
    needed and fills it with the contents of the root filesystem pointed
-   to by the ``-r`` command-line option or the equivalent rootfs derived
+   to by the ``-r`` command-line option or the equivalent root filesystem derived
    from the ``-e`` command-line option. The filesystem type used to
    create the partition is driven by the value of the ``--fstype``
    option specified for the partition. See the entry on ``--fstype``
@@ -96,7 +96,7 @@ the ``part`` and ``partition`` commands:
    If you use ``--source plugin-name``, Wic creates a partition as large
    as needed and fills it with the contents of the partition that is
    generated by the specified plugin name using the data pointed to by
-   the ``-r`` command-line option or the equivalent rootfs derived from
+   the ``-r`` command-line option or the equivalent root filesystem derived from
    the ``-e`` command-line option. Exactly what those contents are and
    filesystem type used are dependent on the given plugin
    implementation.

documentation/ref-manual/variables.rst

@@ -5302,7 +5302,7 @@ system and gives an overview of their function and contents.
    :term:`PACKAGE_WRITE_DEPS`
       Specifies a list of dependencies for post-installation and
       pre-installation scripts on native/cross tools. If your
-      post-installation or pre-installation script can execute at rootfs
+      post-installation or pre-installation script can execute at root filesystem
       creation time rather than on the target but depends on a native tool
       in order to execute, you need to list the tools in
       :term:`PACKAGE_WRITE_DEPS`.