[Qemu-devel] [PATCH v2 0/2] docs/memory.txt: Fixes on whitespace and MMIO operations

[Qemu-devel] [PATCH v2 0/2] docs/memory.txt: Fixes on whitespace and MMIO operations

[Fam Zheng]

Fam Zheng (2):
  docs/memory.txt: Put one whitespace between sentences
  docs/memory.txt: Fix document on MMIO operations

 docs/memory.txt | 47 ++++++++++++++++++++++++-----------------------
 1 file changed, 24 insertions(+), 23 deletions(-)

-- 
1.9.2

[Qemu-devel] [PATCH v2 1/2] docs/memory.txt: Put one whitespace between sentences

[Fam Zheng]

In other words, whitespace changes only.

Signed-off-by: Fam Zheng <famz@redhat.com>
---
 docs/memory.txt | 42 +++++++++++++++++++++---------------------
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/docs/memory.txt b/docs/memory.txt
index d344879..d5abc92 100644
--- a/docs/memory.txt
+++ b/docs/memory.txt
@@ -2,7 +2,7 @@ The memory API
 ==============
 
 The memory API models the memory and I/O buses and controllers of a QEMU
-machine.  It attempts to allow modelling of:
+machine. It attempts to allow modelling of:
 
  - ordinary RAM
  - memory-mapped I/O (MMIO)
@@ -15,7 +15,7 @@ The memory model provides support for
  - setting up coalesced memory for kvm
  - setting up ioeventfd regions for kvm
 
-Memory is modelled as an acyclic graph of MemoryRegion objects.  Sinks
+Memory is modelled as an acyclic graph of MemoryRegion objects. Sinks
 (leaves) are RAM and MMIO regions, while other nodes represent
 buses, memory controllers, and memory regions that have been rerouted.
 
@@ -36,20 +36,20 @@ MemoryRegion):
   each read or write causes a callback to be called on the host.
 
 - container: a container simply includes other memory regions, each at
-  a different offset.  Containers are useful for grouping several regions
-  into one unit.  For example, a PCI BAR may be composed of a RAM region
+  a different offset. Containers are useful for grouping several regions
+  into one unit. For example, a PCI BAR may be composed of a RAM region
   and an MMIO region.
 
-  A container's subregions are usually non-overlapping.  In some cases it is
+  A container's subregions are usually non-overlapping. In some cases it is
   useful to have overlapping regions; for example a memory controller that
   can overlay a subregion of RAM with MMIO or ROM, or a PCI controller
   that does not prevent card from claiming overlapping BARs.
 
-- alias: a subsection of another region.  Aliases allow a region to be
-  split apart into discontiguous regions.  Examples of uses are memory banks
+- alias: a subsection of another region. Aliases allow a region to be
+  split apart into discontiguous regions. Examples of uses are memory banks
   used when the guest address space is smaller than the amount of RAM
   addressed, or a memory controller that splits main memory to expose a "PCI
-  hole".  Aliases may point to any type of region, including other aliases,
+  hole". Aliases may point to any type of region, including other aliases,
   but an alias may not point back to itself, directly or indirectly.
 
 It is valid to add subregions to a region which is not a pure container
@@ -65,27 +65,27 @@ Subregions cannot be added to an alias region.
 Region names
 ------------
 
-Regions are assigned names by the constructor.  For most regions these are
+Regions are assigned names by the constructor. For most regions these are
 only used for debugging purposes, but RAM regions also use the name to identify
-live migration sections.  This means that RAM region names need to have ABI
+live migration sections. This means that RAM region names need to have ABI
 stability.
 
 Region lifecycle
 ----------------
 
 A region is created by one of the constructor functions (memory_region_init*())
-and destroyed by the destructor (memory_region_destroy()).  In between,
+and destroyed by the destructor (memory_region_destroy()). In between,
 a region can be added to an address space by using memory_region_add_subregion()
-and removed using memory_region_del_subregion().  Region attributes may be
+and removed using memory_region_del_subregion(). Region attributes may be
 changed at any point; they take effect once the region becomes exposed to the
 guest.
 
 Overlapping regions and priority
 --------------------------------
 Usually, regions may not overlap each other; a memory address decodes into
-exactly one target.  In some cases it is useful to allow regions to overlap,
+exactly one target. In some cases it is useful to allow regions to overlap,
 and sometimes to control which of an overlapping regions is visible to the
-guest.  This is done with memory_region_add_subregion_overlap(), which
+guest. This is done with memory_region_add_subregion_overlap(), which
 allows the region to overlap any other region in the same container, and
 specifies a priority that allows the core to decide which of two regions at
 the same address are visible (highest wins).
@@ -190,13 +190,13 @@ ram: ram@0x00000000-0xffffffff
 
 This is a (simplified) PC memory map. The 4GB RAM block is mapped into the
 system address space via two aliases: "lomem" is a 1:1 mapping of the first
-3.5GB; "himem" maps the last 0.5GB at address 4GB.  This leaves 0.5GB for the
+3.5GB; "himem" maps the last 0.5GB at address 4GB. This leaves 0.5GB for the
 so-called PCI hole, that allows a 32-bit PCI bus to exist in a system with
 4GB of memory.
 
 The memory controller diverts addresses in the range 640K-768K to the PCI
-address space.  This is modelled using the "vga-window" alias, mapped at a
-higher priority so it obscures the RAM at the same addresses.  The vga window
+address space. This is modelled using the "vga-window" alias, mapped at a
+higher priority so it obscures the RAM at the same addresses. The vga window
 can be removed by programming the memory controller; this is modelled by
 removing the alias and exposing the RAM underneath.
 
@@ -214,7 +214,7 @@ Attributes
 ----------
 
 Various region attributes (read-only, dirty logging, coalesced mmio, ioeventfd)
-can be changed during the region lifecycle.  They take effect once the region
+can be changed during the region lifecycle. They take effect once the region
 is made visible (which can be immediately, later, or never).
 
 MMIO Operations
@@ -227,12 +227,12 @@ various constraints can be supplied to control how these callbacks are called:
    (in bytes) which the device accepts; accesses outside this range will
    have device and bus specific behaviour (ignored, or machine check)
  - .valid.aligned specifies that the device only accepts naturally aligned
-   accesses.  Unaligned accesses invoke device and bus specific behaviour.
+   accesses. Unaligned accesses invoke device and bus specific behaviour.
  - .impl.min_access_size, .impl.max_access_size define the access sizes
    (in bytes) supported by the *implementation*; other access sizes will be
-   emulated using the ones available.  For example a 4-byte write will be
+   emulated using the ones available. For example a 4-byte write will be
    emulated using four 1-byte writes, if .impl.max_access_size = 1.
  - .impl.valid specifies that the *implementation* only supports unaligned
    accesses; unaligned accesses will be emulated by two aligned accesses.
  - .old_mmio can be used to ease porting from code using
-   cpu_register_io_memory().  It should not be used in new code.
+   cpu_register_io_memory(). It should not be used in new code.
-- 
1.9.2

[Qemu-devel] [PATCH v2 2/2] docs/memory.txt: Fix document on MMIO operations

[Fam Zheng]

.impl.valid should be .impl.unaligned and the description needs some
fixes.

Signed-off-by: Fam Zheng <famz@redhat.com>
---
 docs/memory.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/docs/memory.txt b/docs/memory.txt
index d5abc92..4c7bc43 100644
--- a/docs/memory.txt
+++ b/docs/memory.txt
@@ -232,7 +232,8 @@ various constraints can be supplied to control how these callbacks are called:
    (in bytes) supported by the *implementation*; other access sizes will be
    emulated using the ones available. For example a 4-byte write will be
    emulated using four 1-byte writes, if .impl.max_access_size = 1.
- - .impl.valid specifies that the *implementation* only supports unaligned
-   accesses; unaligned accesses will be emulated by two aligned accesses.
+ - .impl.unaligned specifies that the *implementation* supports unaligned
+   accesses; if false, an unaligned access will be emulated by two aligned
+   accesses.
  - .old_mmio can be used to ease porting from code using
    cpu_register_io_memory(). It should not be used in new code.
-- 
1.9.2

Re: [Qemu-devel] [PATCH v2 0/2] docs/memory.txt: Fixes on whitespace and MMIO operations

[Fam Zheng]

On Mon, 05/05 18:59, Fam Zheng wrote:
> 
> 
> Fam Zheng (2):
>   docs/memory.txt: Put one whitespace between sentences
>   docs/memory.txt: Fix document on MMIO operations

Michael, this is based on Peter's

[PATCH] docs/memory.txt: old_portio has gone, so don't mention it

So you could apply on top.

Thanks,
Fam

Re: [Qemu-devel] [PATCH v2 1/2] docs/memory.txt: Put one whitespace between sentences

[Michael Tokarev]

05.05.2014 14:59, Fam Zheng wrote:
> In other words, whitespace changes only.

>  The memory API models the memory and I/O buses and controllers of a QEMU
> -machine.  It attempts to allow modelling of:
> +machine. It attempts to allow modelling of:

What's the point?  In text form, it is quite often and, to my taste, quite
normal to use 2 spaces after the full-dot (at the end of the sentence), just
like an extra line between paragraphs.  This way, it is easier to separate
sentences between each other.

In real typography, 1.5-sized space is usually used in such places.  But since
plaintext format has no 1.5-sized space, 2 spaces is used.

I'd send an opposite patch, which adds additional space where it is missing.. :)

Thanks,

/mjt

Re: [Qemu-devel] [PATCH v2 0/2] docs/memory.txt: Fixes on whitespace and MMIO operations

[Michael Tokarev]

05.05.2014 15:05, Fam Zheng пишет:
> On Mon, 05/05 18:59, Fam Zheng wrote:
>>
>>
>> Fam Zheng (2):
>>   docs/memory.txt: Put one whitespace between sentences
>>   docs/memory.txt: Fix document on MMIO operations
> 
> Michael, this is based on Peter's
> 
> [PATCH] docs/memory.txt: old_portio has gone, so don't mention it
> 
> So you could apply on top.

I'd rather drop the Peter's patch and apply your first version, so
we don't have 2 halves but one whole :)   I can pick it from your
initial submission ;)

Thanks,

/mjt

Re: [Qemu-devel] [PATCH v2 1/2] docs/memory.txt: Put one whitespace between sentences

[Fam Zheng]

On Mon, 05/05 15:05, Michael Tokarev wrote:
> 05.05.2014 14:59, Fam Zheng wrote:
> > In other words, whitespace changes only.
> 
> >  The memory API models the memory and I/O buses and controllers of a QEMU
> > -machine.  It attempts to allow modelling of:
> > +machine. It attempts to allow modelling of:
> 
> What's the point?  In text form, it is quite often and, to my taste, quite
> normal to use 2 spaces after the full-dot (at the end of the sentence), just
> like an extra line between paragraphs.  This way, it is easier to separate
> sentences between each other.
> 
> In real typography, 1.5-sized space is usually used in such places.  But since
> plaintext format has no 1.5-sized space, 2 spaces is used.
> 
> I'd send an opposite patch, which adds additional space where it is missing.. :)
> 

Well, out of my first reaction on the inconsistency. I just get a feeling on
this controversy by looking at the length of this Wikipedia page's reference
section:

http://en.wikipedia.org/wiki/Sentence_spacing#References

Does NOT matter for me, anyway :)

Thanks,
Fam