qemu-img.texi | 8 ++++++++ 1 file changed, 8 insertions(+)
Signed-off-by: Fam Zheng <famz@redhat.com>
---
qemu-img.texi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/qemu-img.texi b/qemu-img.texi
index fdcf120f36..3aa63aad55 100644
--- a/qemu-img.texi
+++ b/qemu-img.texi
@@ -57,6 +57,14 @@ exclusive with the @var{-O} parameters. It is currently required to also use
the @var{-n} parameter to skip image creation. This restriction may be relaxed
in a future release.
+@item --force-share (-U)
+
+If specified, qemu-img will open the image with shared permissions, which makes
+it less likely to conflict with a running guest's permissions due to image
+locking. For example, this can be used to get the image information (with
+'info' subcommand) when the image is used by a running guest. Note that this
+could produce inconsistent result because of concurrent metadata changes, etc..
+
@item fmt
is the disk image format. It is guessed automatically in most cases. See below
for a description of the supported disk formats.
--
2.14.3
On Thu, Dec 07, 2017 at 04:44:53PM +0800, Fam Zheng wrote: > Signed-off-by: Fam Zheng <famz@redhat.com> > --- > qemu-img.texi | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/qemu-img.texi b/qemu-img.texi > index fdcf120f36..3aa63aad55 100644 > --- a/qemu-img.texi > +++ b/qemu-img.texi > @@ -57,6 +57,14 @@ exclusive with the @var{-O} parameters. It is currently required to also use > the @var{-n} parameter to skip image creation. This restriction may be relaxed > in a future release. > > +@item --force-share (-U) > + > +If specified, qemu-img will open the image with shared permissions, which makes Does 'texi' requires to quote tools like `qemu-img` (or single quotes), to highlight them in documentation? > +it less likely to conflict with a running guest's permissions due to image > +locking. For example, this can be used to get the image information (with > +'info' subcommand) when the image is used by a running guest. Note that this > +could produce inconsistent result because of concurrent metadata changes, etc.. Super nit-pick: an ellipsis[*] is three dots :-), so, when applying you might want to: s/../.../ [*] https://dictionary.cambridge.org/dictionary/english/ellipsis Regardless: Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com> [...] -- /kashyap
On 12/07/2017 04:58 AM, Kashyap Chamarthy wrote: > On Thu, Dec 07, 2017 at 04:44:53PM +0800, Fam Zheng wrote: >> Signed-off-by: Fam Zheng <famz@redhat.com> >> --- >> qemu-img.texi | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/qemu-img.texi b/qemu-img.texi >> index fdcf120f36..3aa63aad55 100644 >> --- a/qemu-img.texi >> +++ b/qemu-img.texi >> @@ -57,6 +57,14 @@ exclusive with the @var{-O} parameters. It is currently required to also use >> the @var{-n} parameter to skip image creation. This restriction may be relaxed >> in a future release. >> >> +@item --force-share (-U) >> + >> +If specified, qemu-img will open the image with shared permissions, which makes > > Does 'texi' requires to quote tools like `qemu-img` (or single quotes), > to highlight them in documentation? Our usual markup appears to be: @code{qemu-img} > >> +it less likely to conflict with a running guest's permissions due to image >> +locking. For example, this can be used to get the image information (with >> +'info' subcommand) when the image is used by a running guest. Note that this >> +could produce inconsistent result because of concurrent metadata changes, etc.. > > Super nit-pick: an ellipsis[*] is three dots :-), so, when applying you > might want to: s/../.../ > > [*] https://dictionary.cambridge.org/dictionary/english/ellipsis Except that both "etc." and "..." independently convey a sense of continuation, which means that using both at once is both redundant (just one will do) and difficult to argue how to typeset (since 'etc.' is often written with an explicit '.' to emphasize that is an abbreviation, does that mean you have to write 'etc.''...' for a total of 4 dots?). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On Thu, 12/07 10:53, Eric Blake wrote: > On 12/07/2017 04:58 AM, Kashyap Chamarthy wrote: > > On Thu, Dec 07, 2017 at 04:44:53PM +0800, Fam Zheng wrote: > >> Signed-off-by: Fam Zheng <famz@redhat.com> > >> --- > >> qemu-img.texi | 8 ++++++++ > >> 1 file changed, 8 insertions(+) > >> > >> diff --git a/qemu-img.texi b/qemu-img.texi > >> index fdcf120f36..3aa63aad55 100644 > >> --- a/qemu-img.texi > >> +++ b/qemu-img.texi > >> @@ -57,6 +57,14 @@ exclusive with the @var{-O} parameters. It is currently required to also use > >> the @var{-n} parameter to skip image creation. This restriction may be relaxed > >> in a future release. > >> > >> +@item --force-share (-U) > >> + > >> +If specified, qemu-img will open the image with shared permissions, which makes > > > > Does 'texi' requires to quote tools like `qemu-img` (or single quotes), > > to highlight them in documentation? > > Our usual markup appears to be: > > @code{qemu-img} Sounds good. > > > > >> +it less likely to conflict with a running guest's permissions due to image > >> +locking. For example, this can be used to get the image information (with > >> +'info' subcommand) when the image is used by a running guest. Note that this > >> +could produce inconsistent result because of concurrent metadata changes, etc.. > > > > Super nit-pick: an ellipsis[*] is three dots :-), so, when applying you > > might want to: s/../.../ > > > > [*] https://dictionary.cambridge.org/dictionary/english/ellipsis > > Except that both "etc." and "..." independently convey a sense of > continuation, which means that using both at once is both redundant > (just one will do) and difficult to argue how to typeset (since 'etc.' > is often written with an explicit '.' to emphasize that is an > abbreviation, does that mean you have to write 'etc.''...' for a total > of 4 dots?). I have the impression that "etc." is more correct than "etc" so I used even at the end of the sensence where there is another period '.', making it "etc..". If ending the paragraph with "etc." is enough, we can drop one ".". Fam
Fam Zheng <famz@redhat.com> writes: > On Thu, 12/07 10:53, Eric Blake wrote: >> On 12/07/2017 04:58 AM, Kashyap Chamarthy wrote: >> > On Thu, Dec 07, 2017 at 04:44:53PM +0800, Fam Zheng wrote: [...] >> >> +it less likely to conflict with a running guest's permissions due to image >> >> +locking. For example, this can be used to get the image information (with >> >> +'info' subcommand) when the image is used by a running guest. Note that this >> >> +could produce inconsistent result because of concurrent metadata changes, etc.. >> > >> > Super nit-pick: an ellipsis[*] is three dots :-), so, when applying you >> > might want to: s/../.../ >> > >> > [*] https://dictionary.cambridge.org/dictionary/english/ellipsis >> >> Except that both "etc." and "..." independently convey a sense of >> continuation, which means that using both at once is both redundant >> (just one will do) and difficult to argue how to typeset (since 'etc.' >> is often written with an explicit '.' to emphasize that is an >> abbreviation, does that mean you have to write 'etc.''...' for a total >> of 4 dots?). > > I have the impression that "etc." is more correct than "etc" It is. > so I used even at > the end of the sensence where there is another period '.', making it "etc..". That's wrong all the same :) https://en.wikipedia.org/wiki/Period_(punctuation)#Abbreviations > If ending the paragraph with "etc." is enough, we can drop one ".". Please do.
On Fri, 12/08 08:42, Markus Armbruster wrote: > Fam Zheng <famz@redhat.com> writes: > > > On Thu, 12/07 10:53, Eric Blake wrote: > >> On 12/07/2017 04:58 AM, Kashyap Chamarthy wrote: > >> > On Thu, Dec 07, 2017 at 04:44:53PM +0800, Fam Zheng wrote: > [...] > >> >> +it less likely to conflict with a running guest's permissions due to image > >> >> +locking. For example, this can be used to get the image information (with > >> >> +'info' subcommand) when the image is used by a running guest. Note that this > >> >> +could produce inconsistent result because of concurrent metadata changes, etc.. > >> > > >> > Super nit-pick: an ellipsis[*] is three dots :-), so, when applying you > >> > might want to: s/../.../ > >> > > >> > [*] https://dictionary.cambridge.org/dictionary/english/ellipsis > >> > >> Except that both "etc." and "..." independently convey a sense of > >> continuation, which means that using both at once is both redundant > >> (just one will do) and difficult to argue how to typeset (since 'etc.' > >> is often written with an explicit '.' to emphasize that is an > >> abbreviation, does that mean you have to write 'etc.''...' for a total > >> of 4 dots?). > > > > I have the impression that "etc." is more correct than "etc" > > It is. > > > so I used even at > > the end of the sensence where there is another period '.', making it "etc..". > > That's wrong all the same :) > > https://en.wikipedia.org/wiki/Period_(punctuation)#Abbreviations > > > If ending the paragraph with "etc." is enough, we can drop one ".". > > Please do. Yes, thanks, v2 sent. Fam
© 2016 - 2024 Red Hat, Inc.