From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Hmuh2-00009x-Ai
	for qemu-devel@nongnu.org; Sat, 12 May 2007 12:43:40 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Hmuh0-00006w-Pt
	for qemu-devel@nongnu.org; Sat, 12 May 2007 12:43:40 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Hmuh0-00006c-LB
	for qemu-devel@nongnu.org; Sat, 12 May 2007 12:43:38 -0400
Received: from relais.videotron.ca ([24.201.245.36])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <jonathan.phenix@videotron.ca>) id 1HmuZR-0002Nt-T9
	for qemu-devel@nongnu.org; Sat, 12 May 2007 12:35:50 -0400
Received: from [192.168.0.100] ([74.56.228.237]) by VL-MO-MR004.ip.videotron.ca
	(Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005))
	with ESMTP id <0JHX00JMTSRMQQA0@VL-MO-MR004.ip.videotron.ca> for
	qemu-devel@nongnu.org; Sat, 12 May 2007 12:35:47 -0400 (EDT)
Date: Sat, 12 May 2007 12:35:46 -0400
From: Jonathan Phenix <jonathan.phenix@videotron.ca>
Message-id: <4645ECE2.4050408@videotron.ca>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: QUOTED-PRINTABLE
Subject: [Qemu-devel] Block driver and constant sector size
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Hi,

currently the block driver in qemu only handles blocks (or sectors)=
=20
which are 512 bytes long, this is ideal if the device you are emulati=
ng=20
have a block size which is a multiple of 512. Unfortunately, this is =
not=20
always the case, for example an audio CD (CD-DA) or a CD in mode 2 ha=
ve=20
a sector size of 2352, which is not a multiple of 512. Typical data C=
D=20
are encoded in mode 1 with an ISO9660 file system, and this mode uses=
 a=20
sector size of 2048, which is a multiple of 512, this is the reason w=
hy=20
the problem probably didn't come up yet. You can dump about any CDs i=
n=20
mode 2 under Linux with the "cdrdao read-cd --read-raw [...]" command=
=20
for example.

In order to let the block driver read these raw images, I would like =
to=20
change:

BlockDriverState *bdrv_new(const char *device_name);

to:

BlockDriverState *bdrv_new(const char *device_name, int sector_size);

and change:

int (*bdrv_probe)(const uint8_t *buf, int buf_size, const char *filen=
ame);

of the BlockDriver structure to:

int (*bdrv_probe)(const uint8_t *buf, int buf_size, const char=20
*filename, int sector_size);

Then, each probe functions should be modified to reject sector size=
=20
which is not 512 bytes, except for the raw block driver, which will b=
e=20
modified to accept any block sizes. This change would probably solve =
the=20
whole problem without having a negative impact on the rest of the cod=
e.

Is it the right way to solve the problem? If this solution is accepte=
d,=20
I will code it and submit a patch.

Regards,

Jonathan Ph=E9nix