On 2/3/21 2:08 AM, Eric Blake wrote: > On 2/2/21 4:50 PM, Denis V. Lunev wrote: >> On 2/3/21 1:15 AM, Eric Blake wrote: >>> On 1/28/21 11:21 AM, Vladimir Sementsov-Ogievskiy wrote: >>>> 28.01.2021 20:13, Denis V. Lunev wrote: >>>>> Original specification says that l1 table size if 64 * l1_size, which >>>>> is obviously wrong. The size of the l1 entry is 64 _bits_, not bytes. >>>>> Thus 64 is to be replaces with 8 as specification says about bytes. >>>>> >>>>> There is also minor tweak, field name is renamed from l1 to l1_table, >>>>> which matches with the later text. >>>>> >>>>> Signed-off-by: Denis V. Lunev <d...@openvz.org> >>>>> CC: Stefan Hajnoczi <stefa...@redhat.com> >>>>> CC: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> >>>> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> >>>> >>> I saw the subject "dirty bitmap", and assumed it would go through my >>> dirty bitmap tree. In reality, it's unrelated to the dirty bitmap code. >>> Would an improved subject line help? >> hmm. Actually this is about "how the dirty bitmaps are stored in the >> Parallels Image format". The section is called "dirty bitmap feature". >> >> What I can propose? :) >> >> "docs: fix mistake in Parallels Image "dirty bitmap" feature description" >> >> Will this work for you? > That feels a bit long; maybe just: > > docs: fix Parallels Image "dirty bitmap" section > >
looks great to me. Should I resend? Den