[Qemu-devel] Tiny compliance bug in `block-vvfat.c'

[Qemu-devel] Tiny compliance bug in `block-vvfat.c'

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

[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  <tschwinge@gnu.org>

	* block-vvfat.c (vvfat_open) <floppy>: Use eighteen sectors per track.

Index: block-vvfat.c
===================================================================
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 == NULL) {
 	s->fat_type = 12;
 	s->first_sectors_number = 1;
 	s->sectors_per_cluster=2;
-	bs->cyls = 80; bs->heads = 2; bs->secs = 36;
+	bs->cyls = 80; bs->heads = 2; bs->secs = 18;
     }
 
     if (strstr(dirname, ":32:")) {
#v-


Regards,
 Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [Qemu-devel] Tiny compliance bug in `block-vvfat.c'

[Thiemo Seufer]

Thomas Schwinge wrote:
> [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?  ;-)

It's bad AFAICS. 36 sectors is the right value for a 2.88 MB floppy.


Thiemo