From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HWfnK-0003fl-Mm for qemu-devel@nongnu.org; Wed, 28 Mar 2007 17:35:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HWfnK-0003fW-CO for qemu-devel@nongnu.org; Wed, 28 Mar 2007 17:35:02 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HWfnK-0003fJ-2H for qemu-devel@nongnu.org; Wed, 28 Mar 2007 16:35:02 -0500 Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HWfkn-0003Yp-Po for qemu-devel@nongnu.org; Wed, 28 Mar 2007 17:32:25 -0400 Date: Wed, 28 Mar 2007 23:30:16 +0200 From: Thomas Schwinge Message-ID: <20070328213016.GA28328@fencepost.gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline Subject: [Qemu-devel] Tiny compliance bug in `block-vvfat.c' 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, johannes.schindelin@gmx.de --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [I'm not subscribed to the mailing list, so please keep me cced.] Hello! We kept wondering why the GNU/Hurd's `fatfs' translator (think Unix kernel file system driver) didn't want to ``eat'' the QEMU vvfat on-the-fly served floppy images (created from a directory structure using ``-fdb fat:floppy:some/where'') until we finally traced it down to a tiny QEMU bug in the said vvfat code -- see the following patch. That translator kept telling us that it had expected the file system image to be as twice as big as it actually was. Handling such images was no problem for GNU GRUB and the Linux kernel, but it seems that the GNU/Hurd's fat file system implementation is more obeying to standards. (Now, is that good or bad? ;-) Otherwise, QEMU is working fine for the GNU/Hurd and the GNU/Hurd is working fine in QEMU. If someone wants to give it a try, please speak up. #v+ 2007-03-28 Thomas Schwinge * block-vvfat.c (vvfat_open) : Use eighteen sectors per track. Index: block-vvfat.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /sources/qemu/qemu/block-vvfat.c,v retrieving revision 1.8 diff -u -p -r1.8 block-vvfat.c --- block-vvfat.c 9 Sep 2006 12:03:20 -0000 1.8 +++ block-vvfat.c 28 Mar 2007 21:06:59 -0000 @@ -1002,7 +1002,7 @@ DLOG(if (stderr =3D=3D NULL) { s->fat_type =3D 12; s->first_sectors_number =3D 1; s->sectors_per_cluster=3D2; - bs->cyls =3D 80; bs->heads =3D 2; bs->secs =3D 36; + bs->cyls =3D 80; bs->heads =3D 2; bs->secs =3D 18; } =20 if (strstr(dirname, ":32:")) { #v- Regards, Thomas --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFGCt5ogfzh735dTTURAuPYAJ9GgyNPx/cMBD4jn2YW8MLgcF/k0gCeIj0e Hybs6k+07JYVjplqkdZaASA= =G1pJ -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z--