Re: qemu-img, BSD (was: Re: [Qemu-devel] new block layer)

[Juergen Lock]

In article <address@hidden> you write:
>On Wed, 2004-08-04 at 19:11, Juergen Lock wrote:
>> On Tue, Aug 03, 2004 at 10:19:08PM +0000, Fabrice Bellard wrote:
>> > Hi,
>> > 
>> > I commited the new disk image layer of QEMU which adds the following 
>> > features:
>> > 
>> >...
>> 
>> First: How do you use qemu-img?  If i try
>>      qemu-img create -b /dev/ad0 -f qcow testcow 10M
>> I only get the usage back.
>> 
I just looked at the source and found out that it expects getopt
to support mixing args and options (it doesnt increment optind to skip
over the command before calling getopt), if I change this it works:

Index: qemu/qemu-img.c
@@ -303,7 +303,6 @@
             break;
         }
     }
-    optind++;
     if (optind >= argc) 
         help();
     filename = argv[optind++];
@@ -367,7 +366,6 @@
             break;
         }
     }
-    optind++;
     if (optind >= argc) 
         help();
     filename = argv[optind++];
@@ -505,7 +503,6 @@
             break;
         }
     }
-    optind++;
     if (optind >= argc) 
         help();
     filename = argv[optind++];
@@ -633,7 +630,6 @@
             break;
         }
     }
-    optind++;
     if (optind >= argc) 
         help();
     filename = argv[optind++];
@@ -680,6 +676,7 @@
     if (argc < 2)
         help();
     cmd = argv[1];
+    ++optind;
     if (!strcmp(cmd, "create")) {
         img_create(argc, argv);
     } else if (!strcmp(cmd, "commit")) {

>>  Second question: Has anyone patched the new block layer for BSD already?
>> At least FreeBSD can't access cdroms in 512 byte blocks, everything
>> has to be done in the cd blocksize which is 2048.  (A patch for this
>> from the list for the old block layer is in the port; It also needs
>> to use DIOCGMEDIASIZE but that was quick to re-add.)
>
>I have a new patch for the new block layer - it defines a new block type
>(imaginately called 'dev') and the probe checks the DIOCGMEDIASIZE and
>DIOCGSECTORSIZE ioctls... It also ensures that I/O is done in multiples
>of the device sector size.
>
>I'll have a new patch together for this soon...
>
 Thanks, that would be cool.

>On my machine (FreeBSD 5-NOT_SO_CURRENT), the slirp code causes a
>SIGBUS... I might investigate - it looks like it occurs near
>constructing the ethernet header... poor backtraces prevents me from
>finding exactly where.
>
 Hmm, never seen that here (RELENG_5_2)...

>>  Here is an update for the port, I send it here because I dont
>> think it should be committed until the cdrom issue is fixed...
>> ...

>>  Oh and if you try this after today 2340 (iirc) Jerusalem time
>> you need to adjust the date in DISTNAME (and maybe more depending
>> on what Fabrice commits...)

 You need to change lseek64 to lseek in files/patch-bl now btw.

        Juergen