[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Schwinge
Subject: [Qemu-devel] Tiny compliance bug in `block-vvfat.c'
Date: Wed, 28 Mar 2007 23:30:16 +0200
User-agent: Mutt/1.5.11

[I'm not subscribed to the mailing list, so please keep me cced.]


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

2007-03-28  Thomas Schwinge  <address@hidden>

        * 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;
-       bs->cyls = 80; bs->heads = 2; bs->secs = 36;
+       bs->cyls = 80; bs->heads = 2; bs->secs = 18;
     if (strstr(dirname, ":32:")) {


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]