From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9SPV-0003Q0-Qj for qemu-devel@nongnu.org; Mon, 11 Apr 2011 21:28:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9Pn0-0002uS-2b for qemu-devel@nongnu.org; Mon, 11 Apr 2011 18:40:59 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:45248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9Pmz-0002tA-Oe for qemu-devel@nongnu.org; Mon, 11 Apr 2011 18:40:58 -0400 Received: by gyg4 with SMTP id 4so2923559gyg.4 for ; Mon, 11 Apr 2011 15:40:57 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110411181417.GC8877@lst.de> References: <20110411181417.GC8877@lst.de> Date: Tue, 12 Apr 2011 06:40:56 +0800 Message-ID: From: Lyu Mitnick Content-Type: multipart/alternative; boundary=001636c92431d9925604a0ac4436 Subject: Re: [Qemu-devel] Question about total_sectors in block/vpc.c List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org --001636c92431d9925604a0ac4436 Content-Type: text/plain; charset=ISO-8859-1 Hello Christoph, Stefan I am wondering whether the problem occurred that value of BDRV_SECTOR_SIZE is a macro constant (defined at block.h). This problem could be fixed if we use variable instead of macro to implement BDRV_SECTOR_SIZE. Each block device may reassign the value if needed. Is it right?? Thanks a lot 2011/4/12 Christoph Hellwig > On Sat, Apr 09, 2011 at 09:05:41PM +0100, Stefan Hajnoczi wrote: > > On Sat, Apr 9, 2011 at 5:51 PM, Lyu Mitnick > wrote: > > > Hell all, > > > I have take a look of block/vpc.c and meet a question in > vpc_create().?At > > > the line > > > 550, the code is: > > > total_sectors = options->value.n / 512; > > > I am wondering whether the size between?total_sectors * 512 > > > and?options->value.n > > > would be discard. > > > > Yes, it rounds down. This reflects the assumption that a block device > > cannot be addressed below 512 byte sectors. Because of this block > > devices size must be a multiple of 512 bytes. > > > > I think a reasonable protection would be to have block.c:bdrv_create() > > fail if size is not a multiple of BDRV_SECTOR_SIZE. This way other > > image formats are protected too. > > There are block devices that aren't alignment to 512 bytes. Audio CDROMs > are > the most prominent example, or AS/400 disks. I don't think these matter > for > emulation, but if we'd ever implement DIF/DIX emulation inside qemu we'd > have to store the protection information somewhere. It still wouldn't > work with existing disk format, so adding the above check into the formats > bdrv_create routines sounds fine, but doing it in the core block code > might not be an overly smart idea. > > Mitnick --001636c92431d9925604a0ac4436 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello=A0Christoph,=A0Stefan

I am wondering whether the p= roblem occurred that value of=A0a macro constant (defined= at block.h). This problem could be fixed if we use variable
instead of macro to implement= =A0BDRV_SECTOR_SIZE. Ea= ch block device may reassign
the value if ne= eded. Is it right??

Thanks a lot

2011/4/12 Christoph Hellwig <hch@lst.de>
On Sat, Apr 09, 2011 at= 09:05:41PM +0100, Stefan Hajnoczi wrote:
> On Sat, Apr 9, 2011 at 5:51 PM, Lyu Mitnick <mitnick.lyu@gmail.com> wrote: > > Hell all,
> > I have take a look of block/vpc.c and meet a question in vpc_crea= te().?At
> > the line
> > 550, the code is:
> > total_sectors =3D options->value.n / 512;
> > I am wondering whether the size between?total_sectors * 512
> > and?options->value.n
> > would be discard.
>
> Yes, it rounds down. =A0This reflects the assumption that a block devi= ce
> cannot be addressed below 512 byte sectors. =A0Because of this block > devices size must be a multiple of 512 bytes.
>
> I think a reasonable protection would be to have block.c:bdrv_create()=
> fail if size is not a multiple of BDRV_SECTOR_SIZE. =A0This way other<= br> > image formats are protected too.

There are block devices that aren't alignment to 512 bytes.= =A0Audio CDROMs are
the most prominent example, or AS/400 disks. =A0I don't think these mat= ter for
emulation, but if we'd ever implement DIF/DIX emulation inside qemu we&= #39;d
have to store the protection information somewhere. =A0It still wouldn'= t
work with existing disk format, so adding the above check into the formats<= br> bdrv_create routines sounds fine, but doing it in the core block code
might not be an overly smart idea.


Mitnick
--001636c92431d9925604a0ac4436--