From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hprzj-0005gB-J6 for qemu-devel@nongnu.org; Sun, 20 May 2007 16:27:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hprzh-0005e1-Rl for qemu-devel@nongnu.org; Sun, 20 May 2007 16:27:11 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hprzh-0005ds-Nh for qemu-devel@nongnu.org; Sun, 20 May 2007 16:27:09 -0400 Received: from relais.videotron.ca ([24.201.245.36]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Hprzh-0006II-B4 for qemu-devel@nongnu.org; Sun, 20 May 2007 16:27:09 -0400 Received: from [192.168.0.100] ([74.56.228.237]) by VL-MO-MR003.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0JIC00F1OWT8UIB0@VL-MO-MR003.ip.videotron.ca> for qemu-devel@nongnu.org; Sun, 20 May 2007 16:27:08 -0400 (EDT) Date: Sun, 20 May 2007 16:27:08 -0400 From: Jonathan Phenix Subject: Re: [Qemu-devel] Block driver and constant sector size In-reply-to: <200705182141.36421.paul@codesourcery.com> Message-id: <4650AF1C.1060708@videotron.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE References: <4645ECE2.4050408@videotron.ca> <200705182141.36421.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Paul Brook wrote: > On Saturday 12 May 2007, Jonathan Phenix wrote: > =20 >> Hi, >> >> currently the block driver in qemu only handles blocks (or sectors= ) >> which are 512 bytes long,=20 >> ... >> Then, each probe functions should be modified to reject sector siz= e >> which is not 512 bytes, except for the raw block driver, which wil= l be >> modified to accept any block sizes. This change would probably sol= ve the >> whole problem without having a negative impact on the rest of the = code. >> >> Is it the right way to solve the problem? If this solution is acce= pted, >> I will code it and submit a patch. >> =20 > > Seems like it might just be simpler to have the qemu block ABI use = bytes=20 > rather than blocks. Maybe with some common helper functions for doi= ng R/M/W=20 > on hard sectored devices. > > By adding variable sized sectors you're just shifting complexity fr= om the=20 > block backends to the device emulation. > =20 No, it will not add complexity at all to the device emulation code,= =20 perhaps I was not clear enough on what I was trying to describe.=20 Basically, the only change that would be needed to existing users of = the=20 block driver is to change "bdrv_new(...)" to "bdrv_new(..., 512)" (it= =20 could be also done with "bdrv_open" instead) and that's it. The only= =20 other difference that the user code will see is that the buffer requi= red=20 by bdrv_read, bdrv_write and friends must now be a multiple of the si= ze=20 requested before, but that's to be expected. The block driver will= =20 continue to deal with sectors as a base unit. As for internal changes in the block driver, a new variable, let's ca= ll=20 it "requested_sector_size" will be added to the probe function of eac= h=20 driver as well as the BlockDriver structure. We can simply do "if= =20 (requested_sector_size !=3D 512) return 0;" for all existing drivers = for=20 now in their probe functions and implement it in the future if requir= ed.=20 I will add support for a sector_size that is different than 512 in th= e=20 raw driver, the image file produced by cdrdao is in raw format. Other= =20 popular CD ripping tools for Windows also creates raw images, with ve= ry=20 slight variations, as far as I know. Sounds good? Regards, Jonathan Ph=E9nix > Paul > =20