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 -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org