[Qemu-devel] ping Re: [PATCH v12] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

I do realize you are busy Kevin, but I would
appreciate knowing my patch is in line 
for review.

https://patchwork.ozlabs.org/patch/555945/

On Dec 11, 2015, at 10:27 PM, Programmingkid wrote:

> Mac OS X can be picky when it comes to allowing the user
> to use physical devices in QEMU. Most mounted volumes
> appear to be off limits to QEMU. If an issue is detected,
> a message is displayed showing the user how to unmount a
> volume. Now QEMU uses both CD and DVD media.
> 
> Signed-off-by: John Arbuckle 
> 
> ---
> Removed mediaType parameter from FindEjectableOpticalMedia().
> Added goto statements to hdev_open.
> Replaced snprintf() with g_strdup() in FindEjectableOpticalMedia().
> Put back return statement in hdev_open for Linux compatibility.
> 
> block/raw-posix.c |  163 -
> 1 files changed, 124 insertions(+), 39 deletions(-)
> 
> diff --git a/block/raw-posix.c b/block/raw-posix.c
> index d9162fd..82e8e62 100644
> --- a/block/raw-posix.c
> +++ b/block/raw-posix.c
> @@ -43,6 +43,7 @@
> #include 
> #include 
> //#include 
> +#include 
> #include 
> #endif
> 
> @@ -1975,33 +1976,46 @@ BlockDriver bdrv_file = {
> /* host device */
> 
> #if defined(__APPLE__) && defined(__MACH__)
> -static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
> static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
>CFIndex maxPathSize, int flags);
> -kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
> +static char *FindEjectableOpticalMedia(io_iterator_t *mediaIterator)
> {
> -kern_return_t   kernResult;
> +kern_return_t kernResult = KERN_FAILURE;
>mach_port_t masterPort;
>CFMutableDictionaryRef  classesToMatch;
> +const char *matching_array[] = {kIODVDMediaClass, kIOCDMediaClass};
> +char *mediaType = NULL;
> 
>kernResult = IOMasterPort( MACH_PORT_NULL, &masterPort );
>if ( KERN_SUCCESS != kernResult ) {
>printf( "IOMasterPort returned %d\n", kernResult );
>}
> 
> -classesToMatch = IOServiceMatching( kIOCDMediaClass );
> -if ( classesToMatch == NULL ) {
> -printf( "IOServiceMatching returned a NULL dictionary.\n" );
> -} else {
> -CFDictionarySetValue( classesToMatch, CFSTR( kIOMediaEjectableKey ), 
> kCFBooleanTrue );
> -}
> -kernResult = IOServiceGetMatchingServices( masterPort, classesToMatch, 
> mediaIterator );
> -if ( KERN_SUCCESS != kernResult )
> -{
> -printf( "IOServiceGetMatchingServices returned %d\n", kernResult );
> -}
> +int index;
> +for (index = 0; index < ARRAY_SIZE(matching_array); index++) {
> +classesToMatch = IOServiceMatching(matching_array[index]);
> +if (classesToMatch == NULL) {
> +error_report("IOServiceMatching returned NULL for %s",
> + matching_array[index]);
> +continue;
> +}
> +CFDictionarySetValue(classesToMatch, CFSTR(kIOMediaEjectableKey),
> + kCFBooleanTrue);
> +kernResult = IOServiceGetMatchingServices(masterPort, classesToMatch,
> +  mediaIterator);
> +if (kernResult != KERN_SUCCESS) {
> +error_report("Note: IOServiceGetMatchingServices returned %d",
> + kernResult);
> +}
> 
> -return kernResult;
> +/* If a match was found, leave the loop */
> +if (*mediaIterator != 0) {
> +DPRINTF("Matching using %s\n", matching_array[index]);
> +mediaType = g_strdup(matching_array[index]);
> +break;
> +}
> +}
> +return mediaType;
> }
> 
> kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
> @@ -2033,7 +2047,35 @@ kern_return_t GetBSDPath(io_iterator_t mediaIterator, 
> char *bsdPath,
>return kernResult;
> }
> 
> -#endif
> +/* Sets up a real cdrom for use in QEMU */
> +static bool setup_cdrom(char *bsd_path, Error **errp)
> +{
> +int index, num_of_test_partitions = 2, fd;
> +char test_partition[MAXPATHLEN];
> +bool partition_found = false;
> +
> +/* look for a working partition */
> +for (index = 0; index < num_of_test_partitions; index++) {
> +snprintf(test_partition, sizeof(test_partition), "%ss%d", bsd_path,
> + index);
> +fd = qemu_open(test_partition, O_RDONLY | O_BINARY | O_LARGEFILE);
> +if (fd >= 0) {
> +partition_found = true;
> +qem

qemu-devel@nongnu.org

[Programmingkid]

On Dec 24, 2015, at 5:45 PM, BALATON Zoltan wrote:

> On Thu, 24 Dec 2015, Programmingkid wrote:
>> On Dec 24, 2015, at 10:34 AM, Peter Maydell wrote:
>>> On 24 December 2015 at 01:00, Programmingkid  
>>> wrote:
>>>> I'm having problems with the pci_dma_read() function. When using
>>>> a Mac OS X guest, the data that this function returns is all zeros.
>>>> After doing a lot of instruction tracing, I tracked the problem to a
>>>> function called phys_page_find(). It always returns
>>>> §ions[PHYS_SECTION_UNASSIGNED]. What I would like to know is
>>>> what is an unassigned section? How is memory suppose to be assigned?
>>> 
>>> Unassigned here is an area of the physical address space which has
>>> nothing in it (no RAM, no device, just nothing). Depending on the
>>> guest CPU architecture, accessing this might cause a bus fault
>>> or might just return a dummy value. (It looks like it's the latter
>>> for your case.)
>>> 
>>> One way to get this is if the guest mis-programs the PCI DMA
>>> so that it tries to do DMA from a wrong address. Or maybe the
>>> PCI host controller emulation isn't right and we're not
>>> using the right DMA address. Or there's some RAM or something
>>> that the guest expects to be present in the machine but which
>>> is not implemented by us.
>>> 
>>> You need to find out why we're trying to DMA to/from this
>>> bogus address, I think.
>> 
>> Mac OS X has to give the RTL8139 network interface card an address to a 
>> memory buffer. It is used to send packets to the network interface card from 
>> the guest. How the address is allocated in Mac OS X seems simple enough. 
>> This address is a physical address and not a virtual address, so that seems 
>> good. One address that is used is 0x13d9000. I think that would be around 
>> the 19 MB area. It should be ok for the rtl8139 to access because it is in 
>> the "system" memory region.
> 
> Not sure this is relevant here but previously I've found a patch was 
> necessary to OpenBIOS for me to make DMA work with RTL8139 otherwise sending 
> data was not working correctly. Here's the patch in case it could help or 
> give you an idea:
> 
> http://www.openfirmware.info/pipermail/openbios/2014-June/008363.html
> 
> But it could be your problem is different and the patch is not relevant.
> 
> Regards,
> BALATON Zoltan

Thank you very much for the help. It looks like the Mac OS X driver already 
sets the bus mastering bit. 

qemu-devel@nongnu.org

[Programmingkid]

On Dec 24, 2015, at 10:34 AM, Peter Maydell wrote:

> On 24 December 2015 at 01:00, Programmingkid  
> wrote:
>> I'm having problems with the pci_dma_read() function. When using
>> a Mac OS X guest, the data that this function returns is all zeros.
>> After doing a lot of instruction tracing, I tracked the problem to a
>> function called phys_page_find(). It always returns
>> §ions[PHYS_SECTION_UNASSIGNED]. What I would like to know is
>> what is an unassigned section? How is memory suppose to be assigned?
> 
> Unassigned here is an area of the physical address space which has
> nothing in it (no RAM, no device, just nothing). Depending on the
> guest CPU architecture, accessing this might cause a bus fault
> or might just return a dummy value. (It looks like it's the latter
> for your case.)
> 
> One way to get this is if the guest mis-programs the PCI DMA
> so that it tries to do DMA from a wrong address. Or maybe the
> PCI host controller emulation isn't right and we're not
> using the right DMA address. Or there's some RAM or something
> that the guest expects to be present in the machine but which
> is not implemented by us.
> 
> You need to find out why we're trying to DMA to/from this
> bogus address, I think.

Mac OS X has to give the RTL8139 network interface card an address to a memory 
buffer. It is used to send packets to the network interface card from the 
guest. How the address is allocated in Mac OS X seems simple enough. This 
address is a physical address and not a virtual address, so that seems good. 
One address that is used is 0x13d9000. I think that would be around the 19 MB 
area. It should be ok for the rtl8139 to access because it is in the "system" 
memory region. 

qemu-devel@nongnu.org

[Programmingkid]

I'm having problems with the pci_dma_read() function. When using a Mac OS X 
guest, the data that this function returns is all zeros. After doing a lot of 
instruction tracing, I tracked the problem to a function called 
phys_page_find(). It always returns §ions[PHYS_SECTION_UNASSIGNED]. What I 
would like to know is what is an unassigned section? How is memory suppose to 
be assigned? 

The pci_dma_read() function call I'm tracking takes place in rtl8139.c in case 
anyone would like to know. 

[Qemu-devel] ping Re: [PATCH v12] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

https://patchwork.ozlabs.org/patch/555945/

On Dec 11, 2015, at 10:27 PM, Programmingkid wrote:

> Mac OS X can be picky when it comes to allowing the user
> to use physical devices in QEMU. Most mounted volumes
> appear to be off limits to QEMU. If an issue is detected,
> a message is displayed showing the user how to unmount a
> volume. Now QEMU uses both CD and DVD media.
> 
> Signed-off-by: John Arbuckle 
> 
> ---
> Removed mediaType parameter from FindEjectableOpticalMedia().
> Added goto statements to hdev_open.
> Replaced snprintf() with g_strdup() in FindEjectableOpticalMedia().
> Put back return statement in hdev_open for Linux compatibility.
> 
> block/raw-posix.c |  163 -
> 1 files changed, 124 insertions(+), 39 deletions(-)
> 
> diff --git a/block/raw-posix.c b/block/raw-posix.c
> index d9162fd..82e8e62 100644
> --- a/block/raw-posix.c
> +++ b/block/raw-posix.c
> @@ -43,6 +43,7 @@
> #include 
> #include 
> //#include 
> +#include 
> #include 
> #endif
> 
> @@ -1975,33 +1976,46 @@ BlockDriver bdrv_file = {
> /* host device */
> 
> #if defined(__APPLE__) && defined(__MACH__)
> -static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
> static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
> CFIndex maxPathSize, int flags);
> -kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
> +static char *FindEjectableOpticalMedia(io_iterator_t *mediaIterator)
> {
> -kern_return_t   kernResult;
> +kern_return_t kernResult = KERN_FAILURE;
> mach_port_t masterPort;
> CFMutableDictionaryRef  classesToMatch;
> +const char *matching_array[] = {kIODVDMediaClass, kIOCDMediaClass};
> +char *mediaType = NULL;
> 
> kernResult = IOMasterPort( MACH_PORT_NULL, &masterPort );
> if ( KERN_SUCCESS != kernResult ) {
> printf( "IOMasterPort returned %d\n", kernResult );
> }
> 
> -classesToMatch = IOServiceMatching( kIOCDMediaClass );
> -if ( classesToMatch == NULL ) {
> -printf( "IOServiceMatching returned a NULL dictionary.\n" );
> -} else {
> -CFDictionarySetValue( classesToMatch, CFSTR( kIOMediaEjectableKey ), 
> kCFBooleanTrue );
> -}
> -kernResult = IOServiceGetMatchingServices( masterPort, classesToMatch, 
> mediaIterator );
> -if ( KERN_SUCCESS != kernResult )
> -{
> -printf( "IOServiceGetMatchingServices returned %d\n", kernResult );
> -}
> +int index;
> +for (index = 0; index < ARRAY_SIZE(matching_array); index++) {
> +classesToMatch = IOServiceMatching(matching_array[index]);
> +if (classesToMatch == NULL) {
> +error_report("IOServiceMatching returned NULL for %s",
> + matching_array[index]);
> +continue;
> +}
> +CFDictionarySetValue(classesToMatch, CFSTR(kIOMediaEjectableKey),
> + kCFBooleanTrue);
> +kernResult = IOServiceGetMatchingServices(masterPort, classesToMatch,
> +  mediaIterator);
> +if (kernResult != KERN_SUCCESS) {
> +error_report("Note: IOServiceGetMatchingServices returned %d",
> + kernResult);
> +}
> 
> -return kernResult;
> +/* If a match was found, leave the loop */
> +if (*mediaIterator != 0) {
> +DPRINTF("Matching using %s\n", matching_array[index]);
> +mediaType = g_strdup(matching_array[index]);
> +break;
> +}
> +}
> +return mediaType;
> }
> 
> kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
> @@ -2033,7 +2047,35 @@ kern_return_t GetBSDPath(io_iterator_t mediaIterator, 
> char *bsdPath,
> return kernResult;
> }
> 
> -#endif
> +/* Sets up a real cdrom for use in QEMU */
> +static bool setup_cdrom(char *bsd_path, Error **errp)
> +{
> +int index, num_of_test_partitions = 2, fd;
> +char test_partition[MAXPATHLEN];
> +bool partition_found = false;
> +
> +/* look for a working partition */
> +for (index = 0; index < num_of_test_partitions; index++) {
> +snprintf(test_partition, sizeof(test_partition), "%ss%d", bsd_path,
> + index);
> +fd = qemu_open(test_partition, O_RDONLY | O_BINARY | O_LARGEFILE);
> +if (fd >= 0) {
> +partition_found = true;
> +qemu_close(fd);
> +break;
> +}
> +}
> +
> +/* if a 

[Qemu-devel] [PATCH v12] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

Mac OS X can be picky when it comes to allowing the user
to use physical devices in QEMU. Most mounted volumes
appear to be off limits to QEMU. If an issue is detected,
a message is displayed showing the user how to unmount a
volume. Now QEMU uses both CD and DVD media.

Signed-off-by: John Arbuckle 

---
Removed mediaType parameter from FindEjectableOpticalMedia().
Added goto statements to hdev_open.
Replaced snprintf() with g_strdup() in FindEjectableOpticalMedia().
Put back return statement in hdev_open for Linux compatibility.

 block/raw-posix.c |  163 -
 1 files changed, 124 insertions(+), 39 deletions(-)

diff --git a/block/raw-posix.c b/block/raw-posix.c
index d9162fd..82e8e62 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 //#include 
+#include 
 #include 
 #endif
 
@@ -1975,33 +1976,46 @@ BlockDriver bdrv_file = {
 /* host device */
 
 #if defined(__APPLE__) && defined(__MACH__)
-static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
 static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
 CFIndex maxPathSize, int flags);
-kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
+static char *FindEjectableOpticalMedia(io_iterator_t *mediaIterator)
 {
-kern_return_t   kernResult;
+kern_return_t kernResult = KERN_FAILURE;
 mach_port_t masterPort;
 CFMutableDictionaryRef  classesToMatch;
+const char *matching_array[] = {kIODVDMediaClass, kIOCDMediaClass};
+char *mediaType = NULL;
 
 kernResult = IOMasterPort( MACH_PORT_NULL, &masterPort );
 if ( KERN_SUCCESS != kernResult ) {
 printf( "IOMasterPort returned %d\n", kernResult );
 }
 
-classesToMatch = IOServiceMatching( kIOCDMediaClass );
-if ( classesToMatch == NULL ) {
-printf( "IOServiceMatching returned a NULL dictionary.\n" );
-} else {
-CFDictionarySetValue( classesToMatch, CFSTR( kIOMediaEjectableKey ), 
kCFBooleanTrue );
-}
-kernResult = IOServiceGetMatchingServices( masterPort, classesToMatch, 
mediaIterator );
-if ( KERN_SUCCESS != kernResult )
-{
-printf( "IOServiceGetMatchingServices returned %d\n", kernResult );
-}
+int index;
+for (index = 0; index < ARRAY_SIZE(matching_array); index++) {
+classesToMatch = IOServiceMatching(matching_array[index]);
+if (classesToMatch == NULL) {
+error_report("IOServiceMatching returned NULL for %s",
+ matching_array[index]);
+continue;
+}
+CFDictionarySetValue(classesToMatch, CFSTR(kIOMediaEjectableKey),
+ kCFBooleanTrue);
+kernResult = IOServiceGetMatchingServices(masterPort, classesToMatch,
+  mediaIterator);
+if (kernResult != KERN_SUCCESS) {
+error_report("Note: IOServiceGetMatchingServices returned %d",
+ kernResult);
+}
 
-return kernResult;
+/* If a match was found, leave the loop */
+if (*mediaIterator != 0) {
+DPRINTF("Matching using %s\n", matching_array[index]);
+mediaType = g_strdup(matching_array[index]);
+break;
+}
+}
+return mediaType;
 }
 
 kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
@@ -2033,7 +2047,35 @@ kern_return_t GetBSDPath(io_iterator_t mediaIterator, 
char *bsdPath,
 return kernResult;
 }
 
-#endif
+/* Sets up a real cdrom for use in QEMU */
+static bool setup_cdrom(char *bsd_path, Error **errp)
+{
+int index, num_of_test_partitions = 2, fd;
+char test_partition[MAXPATHLEN];
+bool partition_found = false;
+
+/* look for a working partition */
+for (index = 0; index < num_of_test_partitions; index++) {
+snprintf(test_partition, sizeof(test_partition), "%ss%d", bsd_path,
+ index);
+fd = qemu_open(test_partition, O_RDONLY | O_BINARY | O_LARGEFILE);
+if (fd >= 0) {
+partition_found = true;
+qemu_close(fd);
+break;
+}
+}
+
+/* if a working partition on the device was not found */
+if (partition_found == false) {
+error_setg(errp, "Failed to find a working partition on disc");
+} else {
+DPRINTF("Using %s as optical disc\n", test_partition);
+pstrcpy(bsd_path, MAXPATHLEN, test_partition);
+}
+return partition_found;
+}
+#endif /* defined(__APPLE__) && defined(__MACH__) */
 
 static int hdev_probe_device(const char *filename)
 {
@@ -2115,6 +2157,16 @@ static bool hdev_is_sg(BlockDriverState *bs)
 return false;
 }
 
+/* Prints directions on mounting and unmounting a device */
+static void print_unmounting_directions(const char *file_name)
+{
+error_report("If device %s is mounted on the desktop, unmount"
+ " it fi

Re: [Qemu-devel] [Qemu-block] ping [PATCH v11] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

On Dec 11, 2015, at 5:00 PM, Jeff Cody wrote:

> On Thu, Dec 10, 2015 at 09:39:51AM -0500, Programmingkid wrote:
>> https://patchwork.ozlabs.org/patch/550295/
>> 
>> Mac OS X can be picky when it comes to allowing the user
>> to use physical devices in QEMU. Most mounted volumes
>> appear to be off limits to QEMU. If an issue is detected,
>> a message is displayed showing the user how to unmount a
>> volume.
>> 
> 
> This commit message doesn't seem to really match the patch; it is more
> than just a message displayed to the user.  For instance, before it
> looked for just kIOCDMediaClass - now, it searches for kIOCDMediaClass
> and kIODVDMediaClass.

I guess the commit message is a little out of date. How about this:

Mac OS X can be picky when it comes to allowing the user
to use physical devices in QEMU. Most mounted volumes
appear to be off limits to QEMU. If an issue is detected,
a message is displayed showing the user how to unmount a
volume. Also new to this patch is the ability to use DVD
disc.

> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> error_report()'s had their \n, '.', and "Error:" removed.
>> Indentations are now at the left parenthesis rather than
>> at the 80 character mark.
>> Added spaces between the + sign.
>> 
> 
> Also, this patch seems garbled.  When saved via Mutt, or when I view
> it "raw", there are '=20" and '=3D' all around, a sure sign that it is
> (or once was) not plaintext.
> 
> I recommend using git format-patch [1] and git send-email [1] to
> create and send patches - it'll do the Right Thing.

You really see that? I don't know why. The link I provide to the patch in
patchworks shows no problems. The patch itself was sent as a plain text
file.

> 
>> block/raw-posix.c |  135 
>> +++--
>> 1 files changed, 99 insertions(+), 36 deletions(-)
>> 
>> diff --git a/block/raw-posix.c b/block/raw-posix.c
>> index ccfec1c..39e523b 100644
>> --- a/block/raw-posix.c
>> +++ b/block/raw-posix.c
>> @@ -43,6 +43,7 @@
>> #include 
>> #include 
>> //#include 
>> +#include 
>> #include 
>> #endif
>> 
>> @@ -1975,32 +1976,46 @@ BlockDriver bdrv_file = {
>> /* host device */
>> 
>> #if defined(__APPLE__) && defined(__MACH__)
>> -static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
>> static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
>> CFIndex maxPathSize, int flags);
>> -kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
>> +static kern_return_t FindEjectableOpticalMedia(io_iterator_t *mediaIterator,
>> +   char *mediaType)
>> {
>> kern_return_t   kernResult;
>> mach_port_t masterPort;
>> CFMutableDictionaryRef  classesToMatch;
>> +const char *matching_array[] = {kIODVDMediaClass, kIOCDMediaClass};
>> 
>> kernResult = IOMasterPort( MACH_PORT_NULL, &masterPort );
>> if ( KERN_SUCCESS != kernResult ) {
>> printf( "IOMasterPort returned %d\n", kernResult );
>> }
>> 
>> -classesToMatch = IOServiceMatching( kIOCDMediaClass );
>> -if ( classesToMatch == NULL ) {
>> -printf( "IOServiceMatching returned a NULL dictionary.\n" );
>> -} else {
>> -CFDictionarySetValue( classesToMatch, CFSTR( kIOMediaEjectableKey ), 
>> kCFBooleanTrue );
>> -}
>> -kernResult = IOServiceGetMatchingServices( masterPort, classesToMatch, 
>> mediaIterator );
>> -if ( KERN_SUCCESS != kernResult )
>> -{
>> -printf( "IOServiceGetMatchingServices returned %d\n", kernResult );
>> -}
>> +int index;
>> +for (index = 0; index < ARRAY_SIZE(matching_array); index++) {
>> +classesToMatch = IOServiceMatching(matching_array[index]);
>> +if (classesToMatch == NULL) {
>> +error_report("IOServiceMatching returned NULL for %s",
>> + matching_array[index]);
>> +continue;
>> +}
>> +CFDictionarySetValue(classesToMatch, CFSTR(kIOMediaEjectableKey),
>> + kCFBooleanTrue);
>> +kernResult = IOServiceGetMatchingServices(masterPort, 
>> classesToMatch,
>> +  mediaIterator);
>> +if (kernResult != KERN_SUCCESS) {
>> +error

[Qemu-devel] ping [PATCH v11] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

https://patchwork.ozlabs.org/patch/550295/

Mac OS X can be picky when it comes to allowing the user
to use physical devices in QEMU. Most mounted volumes
appear to be off limits to QEMU. If an issue is detected,
a message is displayed showing the user how to unmount a
volume.

Signed-off-by: John Arbuckle 

---
error_report()'s had their \n, '.', and "Error:" removed.
Indentations are now at the left parenthesis rather than
at the 80 character mark.
Added spaces between the + sign.

 block/raw-posix.c |  135 +++--
 1 files changed, 99 insertions(+), 36 deletions(-)

diff --git a/block/raw-posix.c b/block/raw-posix.c
index ccfec1c..39e523b 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 //#include 
+#include 
 #include 
 #endif
 
@@ -1975,32 +1976,46 @@ BlockDriver bdrv_file = {
 /* host device */
 
 #if defined(__APPLE__) && defined(__MACH__)
-static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
 static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
 CFIndex maxPathSize, int flags);
-kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
+static kern_return_t FindEjectableOpticalMedia(io_iterator_t *mediaIterator,
+   char *mediaType)
 {
 kern_return_t   kernResult;
 mach_port_t masterPort;
 CFMutableDictionaryRef  classesToMatch;
+const char *matching_array[] = {kIODVDMediaClass, kIOCDMediaClass};
 
 kernResult = IOMasterPort( MACH_PORT_NULL, &masterPort );
 if ( KERN_SUCCESS != kernResult ) {
 printf( "IOMasterPort returned %d\n", kernResult );
 }
 
-classesToMatch = IOServiceMatching( kIOCDMediaClass );
-if ( classesToMatch == NULL ) {
-printf( "IOServiceMatching returned a NULL dictionary.\n" );
-} else {
-CFDictionarySetValue( classesToMatch, CFSTR( kIOMediaEjectableKey ), 
kCFBooleanTrue );
-}
-kernResult = IOServiceGetMatchingServices( masterPort, classesToMatch, 
mediaIterator );
-if ( KERN_SUCCESS != kernResult )
-{
-printf( "IOServiceGetMatchingServices returned %d\n", kernResult );
-}
+int index;
+for (index = 0; index < ARRAY_SIZE(matching_array); index++) {
+classesToMatch = IOServiceMatching(matching_array[index]);
+if (classesToMatch == NULL) {
+error_report("IOServiceMatching returned NULL for %s",
+ matching_array[index]);
+continue;
+}
+CFDictionarySetValue(classesToMatch, CFSTR(kIOMediaEjectableKey),
+ kCFBooleanTrue);
+kernResult = IOServiceGetMatchingServices(masterPort, classesToMatch,
+  mediaIterator);
+if (kernResult != KERN_SUCCESS) {
+error_report("Note: IOServiceGetMatchingServices returned %d",
+ kernResult);
+}
 
+/* If a match was found, leave the loop */
+if (*mediaIterator != 0) {
+DPRINTF("Matching using %s\n", matching_array[index]);
+snprintf(mediaType, strlen(matching_array[index]) + 1, "%s",
+ matching_array[index]);
+break;
+}
+}
 return kernResult;
 }
 
@@ -2033,7 +2048,35 @@ kern_return_t GetBSDPath(io_iterator_t mediaIterator, 
char *bsdPath,
 return kernResult;
 }
 
-#endif
+/* Sets up a real cdrom for use in QEMU */
+static bool setup_cdrom(char *bsd_path, Error **errp)
+{
+int index, num_of_test_partitions = 2, fd;
+char test_partition[MAXPATHLEN];
+bool partition_found = false;
+
+/* look for a working partition */
+for (index = 0; index < num_of_test_partitions; index++) {
+snprintf(test_partition, sizeof(test_partition), "%ss%d", bsd_path,
+ index);
+fd = qemu_open(test_partition, O_RDONLY | O_BINARY | O_LARGEFILE);
+if (fd >= 0) {
+partition_found = true;
+qemu_close(fd);
+break;
+}
+}
+
+/* if a working partition on the device was not found */
+if (partition_found == false) {
+error_setg(errp, "Failed to find a working partition on disc");
+} else {
+DPRINTF("Using %s as optical disc\n", test_partition);
+pstrcpy(bsd_path, MAXPATHLEN, test_partition);
+}
+return partition_found;
+}
+#endif /* defined(__APPLE__) && defined(__MACH__) */
 
 static int hdev_probe_device(const char *filename)
 {
@@ -2115,6 +2158,17 @@ static bool hdev_is_sg(BlockDriverState *bs)
 return false;
 }
 
+/* Prints directions on mounting and unmounting a device */
+static void print_unmounting_directions(const char *file_name)
+{
+error_report("If device %s is mounted on the desktop, unmount"
+ " it first before using it in QEMU", file_name);
+error_report("Command to unmount dev

Re: [Qemu-devel] [Qemu-block] QEMU being able to use audio cdroms

[Programmingkid]

On Dec 8, 2015, at 1:49 PM, John Snow wrote:

> 
> 
> On 11/25/2015 03:44 PM, Programmingkid wrote:
>> Is there any platform where a guest in QEMU can play an audio cd? If not, is 
>> this a feature that you would allow into QEMU?
>> 
> 
> I haven't tested it, nobody has ever asked. I wouldn't reject patches
> for such a feature, but I likely wouldn't make reviewing them a priority
> either.
> 
> I assume this would be primarily for emulating games/etc that use mixed
> Data/Audio formats?

That could be one reason to do it. I just thought it would be neat to be able 
to play CDs inside a guest.

Re: [Qemu-devel] Networking documentation for a Mac OS X guest

[Programmingkid]

On Dec 5, 2015, at 9:10 AM, Mark Cave-Ayland wrote:

> On 04/12/15 11:46, Peter Maydell wrote:
> 
>> On 4 December 2015 at 11:36, Mark Cave-Ayland
>>  wrote:
>>> Is it worth setting up per-arch homepages on the wiki? This is something
>>> I've thought about recently since most of the information out on the
>>> internet regarding QEMU's ability to run various systems is badly out of
>>> date with regard to SPARC/PPC. Even better if they could go in the left
>>> hand list with easy to remember URLs like /SPARC, /PPC, /ARM etc...
>> 
>> Sounds like a good idea to me. If you'd like to do it please go ahead :-)
> 
> Okay. Here's my initial attempt at a SPARC homepage which contains basic
> info, a compatibility table from my OpenBIOS tests and other useful
> info: http://wiki.qemu.org/SPARC.
> 
> Hopefully this will encourage other maintainers to step forward and do
> something similar :)

Excellent job! I will model the PowerPC page after your page. Do you think you 
could add a few screenshots of qemu-system-sparc running Solaris? Thanks. 

[Qemu-devel] Networking documentation for a Mac OS X guest

[Programmingkid]

I would like to make a little tutorial on how to make networking work for a Mac 
OS X guest. Where would you suggest I put such documentation? The qemu-doc file 
is what I was thinking about using. 

The bulk of the information would be to add "-usb -net none -netdev 
user,id=mynet0 -device usb-net,netdev=mynet0" to QEMU's arguments. I still 
haven't figured out how to share a folder between the host and the guest. When 
I do, that information would probably be placed near this tutorial.

Re: [Qemu-devel] [PATCH 0/5] audio/coreaudio.c: Fix deprecation warnings

[Programmingkid]

On Nov 28, 2015, at 4:55 PM, Peter Maydell wrote:

> The coreaudio.c code has for some years now produced compilation
> warnings about our use of various APIs that were deprecated starting
> with OSX 10.6. This patchset updates our code to use their replacements.
> 
> I have been a bit conservative with the approach to moving away from
> AudioDeviceGetProperty/AudioDeviceSetProperty, because different sources
> on the web suggest either 10.6 or 10.5 was the point at which you could
> move to AudioObjectGetProperty/AudioObjectSetProperty, but I don't have
> a 10.5 system to test with. So I've left the old code in for when building
> on 10.5 (removing it would be a trivial matter of dropping a lot of ifdeffed
> code).
> 
> Incidentally, on the subject of OSX 10.5, I think we should finally
> drop support for it unless anybody would like to volunteer to actually
> test building on it. I'll send a separate email about that.
> 
> (This patch set is intended for 2.6, not 2.5.)
> 
> Peter Maydell (5):
>  audio/coreaudio.c: Factor out use of AudioHardwareGetProperty
>  audio/coreaudio.c: Use new-in-OSX-10.6 API for getting default voice
>  audio/coreaudio.c: Factor out uses of AudioDeviceGet/SetProperty
>  audio/coreaudio.c: Use new-in-OSX-10.6 APIs when available
>  audio/coreaudio.c: Avoid deprecated AudioDeviceAdd/RemoveIOProc APIs
> 
> audio/coreaudio.c | 314 +++---
> 1 file changed, 252 insertions(+), 62 deletions(-)
> 
> -- 
> 2.6.2

All the patches applied and compiled without problem on Mac OS 10.6.8. I played 
video and mp3 files in QEMU running a Windows XP guest. They all played 
perfectly. 

I really was against the idea of removing Mac OS 10.5 support when I first 
heard the idea. But I did think about it before saying anything. I personally 
started out building QEMU on Mac OS 10.3. But that was years ago. Technology 
has moved on. Everyone wants to run their emulator on the fastest hardware they 
have. This hardware is probably not going to include anything running Mac OS 
10.5. Removing Mac OS 10.5 support might be a good idea. I don't think we would 
inconvenience anyone. The only evidence I found of someone using Mac OS 10.5 to 
build QEMU was from 2012. 

We are only removing support for Mac OS 10.5 because of a warning message that 
appears during compilation. We could just disable warnings for that file. But 
the depreciated audio functions might
not be around in the future, so probably better to say goodbye to them now 
before they cause real problems.

[Qemu-devel] [PATCH v11] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

Mac OS X can be picky when it comes to allowing the user
to use physical devices in QEMU. Most mounted volumes
appear to be off limits to QEMU. If an issue is detected,
a message is displayed showing the user how to unmount a
volume.

Signed-off-by: John Arbuckle 

---
error_report()'s had their \n, '.', and "Error:" removed.
Indentations are now at the left parenthesis rather than
at the 80 character mark.
Added spaces between the + sign.

 block/raw-posix.c |  135 +++--
 1 files changed, 99 insertions(+), 36 deletions(-)

diff --git a/block/raw-posix.c b/block/raw-posix.c
index ccfec1c..39e523b 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 //#include 
+#include 
 #include 
 #endif
 
@@ -1975,32 +1976,46 @@ BlockDriver bdrv_file = {
 /* host device */
 
 #if defined(__APPLE__) && defined(__MACH__)
-static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
 static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
 CFIndex maxPathSize, int flags);
-kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
+static kern_return_t FindEjectableOpticalMedia(io_iterator_t *mediaIterator,
+   char *mediaType)
 {
 kern_return_t   kernResult;
 mach_port_t masterPort;
 CFMutableDictionaryRef  classesToMatch;
+const char *matching_array[] = {kIODVDMediaClass, kIOCDMediaClass};
 
 kernResult = IOMasterPort( MACH_PORT_NULL, &masterPort );
 if ( KERN_SUCCESS != kernResult ) {
 printf( "IOMasterPort returned %d\n", kernResult );
 }
 
-classesToMatch = IOServiceMatching( kIOCDMediaClass );
-if ( classesToMatch == NULL ) {
-printf( "IOServiceMatching returned a NULL dictionary.\n" );
-} else {
-CFDictionarySetValue( classesToMatch, CFSTR( kIOMediaEjectableKey ), 
kCFBooleanTrue );
-}
-kernResult = IOServiceGetMatchingServices( masterPort, classesToMatch, 
mediaIterator );
-if ( KERN_SUCCESS != kernResult )
-{
-printf( "IOServiceGetMatchingServices returned %d\n", kernResult );
-}
+int index;
+for (index = 0; index < ARRAY_SIZE(matching_array); index++) {
+classesToMatch = IOServiceMatching(matching_array[index]);
+if (classesToMatch == NULL) {
+error_report("IOServiceMatching returned NULL for %s",
+ matching_array[index]);
+continue;
+}
+CFDictionarySetValue(classesToMatch, CFSTR(kIOMediaEjectableKey),
+ kCFBooleanTrue);
+kernResult = IOServiceGetMatchingServices(masterPort, classesToMatch,
+  mediaIterator);
+if (kernResult != KERN_SUCCESS) {
+error_report("Note: IOServiceGetMatchingServices returned %d",
+ kernResult);
+}
 
+/* If a match was found, leave the loop */
+if (*mediaIterator != 0) {
+DPRINTF("Matching using %s\n", matching_array[index]);
+snprintf(mediaType, strlen(matching_array[index]) + 1, "%s",
+ matching_array[index]);
+break;
+}
+}
 return kernResult;
 }
 
@@ -2033,7 +2048,35 @@ kern_return_t GetBSDPath(io_iterator_t mediaIterator, 
char *bsdPath,
 return kernResult;
 }
 
-#endif
+/* Sets up a real cdrom for use in QEMU */
+static bool setup_cdrom(char *bsd_path, Error **errp)
+{
+int index, num_of_test_partitions = 2, fd;
+char test_partition[MAXPATHLEN];
+bool partition_found = false;
+
+/* look for a working partition */
+for (index = 0; index < num_of_test_partitions; index++) {
+snprintf(test_partition, sizeof(test_partition), "%ss%d", bsd_path,
+ index);
+fd = qemu_open(test_partition, O_RDONLY | O_BINARY | O_LARGEFILE);
+if (fd >= 0) {
+partition_found = true;
+qemu_close(fd);
+break;
+}
+}
+
+/* if a working partition on the device was not found */
+if (partition_found == false) {
+error_setg(errp, "Failed to find a working partition on disc");
+} else {
+DPRINTF("Using %s as optical disc\n", test_partition);
+pstrcpy(bsd_path, MAXPATHLEN, test_partition);
+}
+return partition_found;
+}
+#endif /* defined(__APPLE__) && defined(__MACH__) */
 
 static int hdev_probe_device(const char *filename)
 {
@@ -2115,6 +2158,17 @@ static bool hdev_is_sg(BlockDriverState *bs)
 return false;
 }
 
+/* Prints directions on mounting and unmounting a device */
+static void print_unmounting_directions(const char *file_name)
+{
+error_report("If device %s is mounted on the desktop, unmount"
+ " it first before using it in QEMU", file_name);
+error_report("Command to unmount device: diskutil unmountDisk %s",
+

Re: [Qemu-devel] [PATCH v10] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

On Nov 30, 2015, at 11:26 AM, Eric Blake wrote:

> On 11/27/2015 02:49 PM, Programmingkid wrote:
>> Mac OS X can be picky when it comes to allowing the user
>> to use physical devices in QEMU. Most mounted volumes
>> appear to be off limits to QEMU. If an issue is detected,
>> a message is displayed showing the user how to unmount a
>> volume.
>> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> Fixed some spacing issues. 
>> Removed else condition in FindEjectableOpticalMedia.
>> Added continue statement to FindEjectableOpticalMedia.
>> Replaced printf() with error_report() in FindEjectableOpticalMedia.
>> Altered comment in FindEjectableOpticalMedia.
>> If the spacing in this patch looks off, try changing the font to something
>> that is mono-spaced.
> 
> Patches are best read in monospaced fonts, anyways; it's better to make
> that part of your workflow, and assume that everyone else has already
> done likewise, than to advertise that you are only making life harder
> for yourself.
> 
>> 
>> block/raw-posix.c |  140 ++--
>> 1 files changed, 102 insertions(+), 38 deletions(-)
>> 
>> diff --git a/block/raw-posix.c b/block/raw-posix.c
>> index ccfec1c..9e7de11 100644
>> --- a/block/raw-posix.c
>> +++ b/block/raw-posix.c
>> @@ -42,9 +42,9 @@
>> #include 
>> #include 
>> #include 
>> -//#include 
>> +#include 
>> #include 
>> -#endif
>> +#endif /* (__APPLE__) && (__MACH__) */
>> 
> 
> I have now mentioned in both v8 and v9 that this hunk should be its own
> patch (and is simple enough to cc qemu-trivial).  Disregarding reviewers
> suggestions is not a good idea - it only serves to waste time (both
> yours and reviewers) and earn you black marks, such that it will be even
> less likely that anyone wants to review your patches in the first place.
> I'm trying to help you be a better contributor, but it feels like you
> are ignoring advice, and so my natural reaction is to ignore you.

I assure you that this change is *required* for my patch. Without it the patch 
would
not even compile. I need a macro from IODVDMedia.h. If removing the IOCDTypes.h
is what is bothering you, it is a very small change that no one is going to 
miss. That
header file was commented out but not removed for some reason. 

I do thank you for your patients. I think it might be better if instead of 
saying "this is wrong",
you talk about what should be done differently more.

> 
>> #ifdef __sun__
>> #define _POSIX_PTHREAD_SEMANTICS 1
>> @@ -1975,32 +1975,46 @@ BlockDriver bdrv_file = {
>> /* host device */
>> 
>> #if defined(__APPLE__) && defined(__MACH__)
>> -static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
>> static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
>> CFIndex maxPathSize, int flags);
>> -kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
>> +static kern_return_t FindEjectableOpticalMedia(io_iterator_t *mediaIterator,
>> +char 
>> *mediaType)
> 
> No, your indentation is still wrong.  I tried to point out on your v8
> that we don't right-justify to 80 columns, but rather left-justify to
> the point just after the (.

If you feel it is that important, I will do it. I just thought it was easier to 
read when your
eye is already in the area. There is less time spend finding the next argument 
that way.

> 
>> +int index;
>> +for (index = 0; index < ARRAY_SIZE(matching_array); index++) {
>> +classesToMatch = IOServiceMatching(matching_array[index]);
>> +if (classesToMatch == NULL) {
>> +error_report("IOServiceMatching returned NULL for %s.\n",
> 
> No. Don't use trailing '.' or trailing '\n' in error_report() calls.
> I've already mentioned this, and feel like I'm becoming a broken record.
> When you disregard my review comments, I become disinclined to review
> your patches any further.

I don't remember hearing about not using \n in the error_report() call, but I 
will
fix this in the next patch.

> 
>> + 
>> matching_array[index]);
> 
> Indentation is still wrong.

Will left justify with the left parenthesis. 

> 
>> +continue;
>> +}
>> +CFDictionarySetValue(classesToMatch, CFSTR(kIOMediaEjectableKey),
>> +
>> k

Re: [Qemu-devel] [PATCH v9] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

On Nov 30, 2015, at 11:26 AM, Kevin Wolf wrote:

> Am 30.11.2015 um 17:19 hat Eric Blake geschrieben:
>> On 11/27/2015 12:35 PM, Programmingkid wrote:
>> 
>>>> Unusual indentation; more typical is:
>>>> 
>>>> | static kern_return_t FindEjectableOpticalMedia(io_iterator_t
>>>> *mediaIterator,
>>>> | char *mediatType)
>>> 
>>> I agree. I wanted the second long to be right justified with the 80 
>>> character line count.
>> 
>> No.  We don't right-justify code to 80 columns.  That's not how it is
>> done.  Trying to do it just makes you look like the proverbial 'kid' in
>> your pseudonym, rather than an adult to be taken seriously.
>> 
>> Really, PLEASE follow the indentation patterns of the rest of the code
>> base - where continued lines are left-justified to be underneath the
>> character after (, and NOT right-justified to 80 columns.  Violating
>> style doesn't make your code invalid, but does make your patches less
>> likely to be applied.
>> 
>> 
>>>>> +/* If you found a match, leave the loop */
>>>>> +if (*mediaIterator != 0) {
>>>>> +DPRINTF("Matching using %s\n", matching_array[index]);
>>>>> +snprintf(mediaType, strlen(matching_array[index])+1, "%s",
>>>> 
>>>> Spaces around binary '+'.
>>> 
>>> What's wrong with no spaces around the plus sign?
>> 
>> Again, the prevailing conventions in the code base is that you put
>> spaces around every binary operator.  Yes, there is existing old code
>> that does not meet the conventions, but it is not an excuse to add new
>> code that is gratuitously different.
>> 
>>> 
>>>> 
>>>>> +/* if a working partition on the device was not found */
>>>>> +if (partition_found == false) {
>>>>> +error_setg(errp, "Error: Failed to find a working partition on "
>>>>> + 
>>>>> "disc!\n");
>>>> 
>>>> and I already pointed out on v8 that this is not the correct usage of
>>>> error_setg().  So, here's hoping v10 addresses the comments here and
>>>> elsewhere.
>>> 
>>> Kevin Wolf wanted it this way. What would you do instead?
>> 
>> Keven and I both want you to use error_setg(), but to use it correctly -
>> and the correct way is to NOT supply a trailing \n.
> 
> Nor leading "Error:", for that matter.

I just think that using "Error" does communicate the fact that something is 
wrong
a lot better than just printing the message. 

[Qemu-devel] [PATCH v10] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

Mac OS X can be picky when it comes to allowing the user
to use physical devices in QEMU. Most mounted volumes
appear to be off limits to QEMU. If an issue is detected,
a message is displayed showing the user how to unmount a
volume.

Signed-off-by: John Arbuckle 

---
Fixed some spacing issues. 
Removed else condition in FindEjectableOpticalMedia.
Added continue statement to FindEjectableOpticalMedia.
Replaced printf() with error_report() in FindEjectableOpticalMedia.
Altered comment in FindEjectableOpticalMedia.
If the spacing in this patch looks off, try changing the font to something
that is mono-spaced.

 block/raw-posix.c |  140 ++--
 1 files changed, 102 insertions(+), 38 deletions(-)

diff --git a/block/raw-posix.c b/block/raw-posix.c
index ccfec1c..9e7de11 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -42,9 +42,9 @@
 #include 
 #include 
 #include 
-//#include 
+#include 
 #include 
-#endif
+#endif /* (__APPLE__) && (__MACH__) */
 
 #ifdef __sun__
 #define _POSIX_PTHREAD_SEMANTICS 1
@@ -1975,32 +1975,46 @@ BlockDriver bdrv_file = {
 /* host device */
 
 #if defined(__APPLE__) && defined(__MACH__)
-static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
 static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
 CFIndex maxPathSize, int flags);
-kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
+static kern_return_t FindEjectableOpticalMedia(io_iterator_t *mediaIterator,
+char 
*mediaType)
 {
 kern_return_t   kernResult;
 mach_port_t masterPort;
 CFMutableDictionaryRef  classesToMatch;
+const char *matching_array[] = {kIODVDMediaClass, kIOCDMediaClass};
 
 kernResult = IOMasterPort( MACH_PORT_NULL, &masterPort );
 if ( KERN_SUCCESS != kernResult ) {
 printf( "IOMasterPort returned %d\n", kernResult );
 }
 
-classesToMatch = IOServiceMatching( kIOCDMediaClass );
-if ( classesToMatch == NULL ) {
-printf( "IOServiceMatching returned a NULL dictionary.\n" );
-} else {
-CFDictionarySetValue( classesToMatch, CFSTR( kIOMediaEjectableKey ), 
kCFBooleanTrue );
-}
-kernResult = IOServiceGetMatchingServices( masterPort, classesToMatch, 
mediaIterator );
-if ( KERN_SUCCESS != kernResult )
-{
-printf( "IOServiceGetMatchingServices returned %d\n", kernResult );
-}
+int index;
+for (index = 0; index < ARRAY_SIZE(matching_array); index++) {
+classesToMatch = IOServiceMatching(matching_array[index]);
+if (classesToMatch == NULL) {
+error_report("IOServiceMatching returned NULL for %s.\n",
+ 
matching_array[index]);
+continue;
+}
+CFDictionarySetValue(classesToMatch, CFSTR(kIOMediaEjectableKey),
+
kCFBooleanTrue);
+kernResult = IOServiceGetMatchingServices(masterPort, classesToMatch,
+ 
mediaIterator);
+if (kernResult != KERN_SUCCESS) {
+error_report("Note: IOServiceGetMatchingServices returned %d\n",
+
kernResult);
+}
 
+/* If a match was found, leave the loop */
+if (*mediaIterator != 0) {
+DPRINTF("Matching using %s\n", matching_array[index]);
+snprintf(mediaType, strlen(matching_array[index])+1, "%s",
+ 
matching_array[index]);
+break;
+}
+}
 return kernResult;
 }
 
@@ -2033,7 +2047,36 @@ kern_return_t GetBSDPath(io_iterator_t mediaIterator, 
char *bsdPath,
 return kernResult;
 }
 
-#endif
+/* Sets up a real cdrom for use in QEMU */
+static bool setup_cdrom(char *bsd_path, Error **errp)
+{
+int index, num_of_test_partitions = 2, fd;
+char test_partition[MAXPATHLEN];
+bool partition_found = false;
+
+/* look for a working partition */
+for (index = 0; index < num_of_test_partitions; index++) {
+snprintf(test_partition, sizeof(test_partition), "%ss%d", bsd_path,
+ 
index);
+fd = qemu_open(test_partition, O_RDONLY | O_BINARY | O_LARGEFILE);
+if (fd >= 0) {
+partition_found = true;
+qemu_close(fd);
+break;
+}
+}
+
+/* if a working partition on the device was not found */
+if (partition_found == false) {
+error_setg(errp, "Error: Failed to find a working partition on "
+ 
"disc!\n");
+} else {
+DPRINTF("Using %s as optical disc\n", test_partition);
+pstrcpy(bsd_path, MAXPATHLEN, test

Re: [Qemu-devel] [PATCH v9] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

On Nov 25, 2015, at 11:29 PM, Eric Blake wrote:

> On 11/25/2015 09:23 PM, Eric Blake wrote:
> 
>>> +static kern_return_t FindEjectableOpticalMedia(io_iterator_t 
>>> *mediaIterator,
>>> +char 
>>> *mediaType)
>> 
>> Unusual indentation; more typical is:
>> 
>> | static kern_return_t FindEjectableOpticalMedia(io_iterator_t
>> *mediaIterator,
>> | char *mediatType)
> 
> And then my mailer messes it up :(
> 
>> static kern_return_t FindEjectableOpticalMedia(io_iterator_t *mediaIterator,
>>   char *mediatType)
> 
> Let's see if that's better (the 'char' is directly beneath the
> 'io_iterator_t').

In my email program, the 'char' appears underneath the Ejectable word. When I 
change the font to monaco (A mono-spaced font), the 'char' does appear 
underneath the io_iterator_t. 

Re: [Qemu-devel] [PATCH v9] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

On Nov 25, 2015, at 11:23 PM, Eric Blake wrote:

> On 11/25/2015 09:10 PM, Programmingkid wrote:
>> Mac OS X can be picky when it comes to allowing the user
>> to use physical devices in QEMU. Most mounted volumes
>> appear to be off limits to QEMU. If an issue is detected,
>> a message is displayed showing the user how to unmount a
>> volume.
>> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> Added DVD support - real DVD media can now be used in QEMU!
>> Changed name of FindEjectableCDMedia to FindEjectableOpticalMedia.
>> Added mediaType parameter to FindEjectableOpticalMedia() for media 
>> indentification.
>> Removed unneeded FindEjectableCDMedia() prototype.
>> FindEjectableOpticalMedia() now searches for both DVD's and CD's.
>> 
> 
>> +++ b/block/raw-posix.c
>> @@ -42,9 +42,9 @@
>> #include 
>> #include 
>> #include 
>> -//#include 
>> +#include 
>> #include 
>> -#endif
>> +#endif /* (__APPLE__) && (__MACH__) */
>> 
> 
> I don't know if my review of v8 crossed your posting of this patch, but
> I suggested that this hunk belongs in its own patch.

It is now a related change that the code in the patch depends on.

> 
>> #ifdef __sun__
>> #define _POSIX_PTHREAD_SEMANTICS 1
>> @@ -1975,32 +1975,44 @@ BlockDriver bdrv_file = {
>> /* host device */
>> 
>> #if defined(__APPLE__) && defined(__MACH__)
>> -static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
>> static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
>> CFIndex maxPathSize, int flags);
>> -kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
>> +static kern_return_t FindEjectableOpticalMedia(io_iterator_t *mediaIterator,
>> +char 
>> *mediaType)
> 
> Unusual indentation; more typical is:
> 
> | static kern_return_t FindEjectableOpticalMedia(io_iterator_t
> *mediaIterator,
> | char *mediatType)

I agree. I wanted the second long to be right justified with the 80 character 
line count.

> 
> 
>> +int index;
>> +for (index = 0; index < ARRAY_SIZE(matching_array); index++) {
>> +classesToMatch = IOServiceMatching(matching_array[index]);
>> +if (classesToMatch == NULL) {
>> +printf("IOServiceMatching returned a NULL dictionary.\n");
> 
> Leftover debugging?

It is actually how the function was originally written. It probably needs to be 
improved.
Should I replace printf() with error_report()?

> 
>> +} else {
>> +CFDictionarySetValue(classesToMatch, CFSTR(kIOMediaEjectableKey),
> 
> Missing indentation.

Fixed in the next patch.

> 
>> +
>> kCFBooleanTrue);
>> +}
>> +kernResult = IOServiceGetMatchingServices(masterPort, 
>> classesToMatch,
>> + 
>> mediaIterator);
> 
> More unusual indentation.

Fixed in the next patch. 

> 
>> +if (KERN_SUCCESS != kernResult) {
>> +printf("IOServiceGetMatchingServices returned %d\n", 
>> kernResult);
>> +}
>> 
>> +/* If you found a match, leave the loop */
>> +if (*mediaIterator != 0) {
>> +DPRINTF("Matching using %s\n", matching_array[index]);
>> +snprintf(mediaType, strlen(matching_array[index])+1, "%s",
> 
> Spaces around binary '+'.

What's wrong with no spaces around the plus sign?

> 
>> +/* if a working partition on the device was not found */
>> +if (partition_found == false) {
>> +error_setg(errp, "Error: Failed to find a working partition on "
>> + 
>> "disc!\n");
> 
> and I already pointed out on v8 that this is not the correct usage of
> error_setg().  So, here's hoping v10 addresses the comments here and
> elsewhere.

Kevin Wolf wanted it this way. What would you do instead?

> 
> -- 
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

Thank you very much for reviewing my patches.

Re: [Qemu-devel] [PATCH v2] ui/cocoa.m: Prevent activation clicks from going to guest

[Programmingkid]

On Nov 26, 2015, at 6:45 AM, Peter Maydell wrote:

> On 26 November 2015 at 01:14, Programmingkid  
> wrote:
>> When QEMU is brought to the foreground, the click event that activates QEMU
>> should not go to the guest. Accidents happen when they do go to the guest
>> without giving the user a change to handle them. Buttons are clicked 
>> accidently.
>> Windows are closed accidently. Volumes are unmounted accidently. This patch
>> prevents these accidents from happening.
>> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> Added code that handles the right mouse button and the other mouse button.
> 
> This seems like a fair bit of repeated code. Does the change
> below do the right thing?
YES! Excellent job with this one. It's very compact. 

> I think it ought to work but I don't have
> any guests handy which use the mouse to check with.

Really? This Debian distro should fix that: 
http://cdimage.debian.org/cdimage/archive/5.0.10/powerpc/iso-cd/

> 
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index 1554331..d76b942 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -724,7 +724,15 @@ QemuCocoaView *cocoaView;
> }
> 
> if (mouse_event) {
> -if (last_buttons != buttons) {
> +/* Don't send button events to the guest unless we've got a
> + * mouse grab or window focus. If we have neither then this event
> + * is the user clicking on the background window to activate and
> + * bring us to the front, which will be done by the sendEvent
> + * call below. We definitely don't want to pass that click through
> + * to the guest.
> + */
> +if ((isMouseGrabbed || [[self window] isKeyWindow]) &&
> +(last_buttons != buttons)) {
> static uint32_t bmap[INPUT_BUTTON_MAX] = {
> [INPUT_BUTTON_LEFT]   = MOUSE_EVENT_LBUTTON,
> [INPUT_BUTTON_MIDDLE] = MOUSE_EVENT_MBUTTON,
> 
> 
> 
> (if this is the activation click then we will do the mousegrab
> on mouse-button-up so it's not necessary to do it on button-down,
> I think.)
> 
> thanks
> -- PMM

Reviewed-by: John Arbuckle 

[Qemu-devel] [PATCH v9] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

Mac OS X can be picky when it comes to allowing the user
to use physical devices in QEMU. Most mounted volumes
appear to be off limits to QEMU. If an issue is detected,
a message is displayed showing the user how to unmount a
volume.

Signed-off-by: John Arbuckle 

---
Added DVD support - real DVD media can now be used in QEMU!
Changed name of FindEjectableCDMedia to FindEjectableOpticalMedia.
Added mediaType parameter to FindEjectableOpticalMedia() for media 
indentification.
Removed unneeded FindEjectableCDMedia() prototype.
FindEjectableOpticalMedia() now searches for both DVD's and CD's.

 block/raw-posix.c |  138 ++---
 1 files changed, 100 insertions(+), 38 deletions(-)

diff --git a/block/raw-posix.c b/block/raw-posix.c
index ccfec1c..a11a9e7 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -42,9 +42,9 @@
 #include 
 #include 
 #include 
-//#include 
+#include 
 #include 
-#endif
+#endif /* (__APPLE__) && (__MACH__) */
 
 #ifdef __sun__
 #define _POSIX_PTHREAD_SEMANTICS 1
@@ -1975,32 +1975,44 @@ BlockDriver bdrv_file = {
 /* host device */
 
 #if defined(__APPLE__) && defined(__MACH__)
-static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
 static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
 CFIndex maxPathSize, int flags);
-kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
+static kern_return_t FindEjectableOpticalMedia(io_iterator_t *mediaIterator,
+char 
*mediaType)
 {
 kern_return_t   kernResult;
 mach_port_t masterPort;
 CFMutableDictionaryRef  classesToMatch;
+const char *matching_array[] = {kIODVDMediaClass, kIOCDMediaClass};
 
 kernResult = IOMasterPort( MACH_PORT_NULL, &masterPort );
 if ( KERN_SUCCESS != kernResult ) {
 printf( "IOMasterPort returned %d\n", kernResult );
 }
 
-classesToMatch = IOServiceMatching( kIOCDMediaClass );
-if ( classesToMatch == NULL ) {
-printf( "IOServiceMatching returned a NULL dictionary.\n" );
-} else {
-CFDictionarySetValue( classesToMatch, CFSTR( kIOMediaEjectableKey ), 
kCFBooleanTrue );
-}
-kernResult = IOServiceGetMatchingServices( masterPort, classesToMatch, 
mediaIterator );
-if ( KERN_SUCCESS != kernResult )
-{
-printf( "IOServiceGetMatchingServices returned %d\n", kernResult );
-}
+int index;
+for (index = 0; index < ARRAY_SIZE(matching_array); index++) {
+classesToMatch = IOServiceMatching(matching_array[index]);
+if (classesToMatch == NULL) {
+printf("IOServiceMatching returned a NULL dictionary.\n");
+} else {
+CFDictionarySetValue(classesToMatch, CFSTR(kIOMediaEjectableKey),
+
kCFBooleanTrue);
+}
+kernResult = IOServiceGetMatchingServices(masterPort, classesToMatch,
+ 
mediaIterator);
+if (KERN_SUCCESS != kernResult) {
+printf("IOServiceGetMatchingServices returned %d\n", kernResult);
+}
 
+/* If you found a match, leave the loop */
+if (*mediaIterator != 0) {
+DPRINTF("Matching using %s\n", matching_array[index]);
+snprintf(mediaType, strlen(matching_array[index])+1, "%s",
+ 
matching_array[index]);
+break;
+}
+}
 return kernResult;
 }
 
@@ -2033,7 +2045,36 @@ kern_return_t GetBSDPath(io_iterator_t mediaIterator, 
char *bsdPath,
 return kernResult;
 }
 
-#endif
+/* Sets up a real cdrom for use in QEMU */
+static bool setup_cdrom(char *bsd_path, Error **errp)
+{
+int index, num_of_test_partitions = 2, fd;
+char test_partition[MAXPATHLEN];
+bool partition_found = false;
+
+/* look for a working partition */
+for (index = 0; index < num_of_test_partitions; index++) {
+snprintf(test_partition, sizeof(test_partition), "%ss%d", bsd_path,
+ 
index);
+fd = qemu_open(test_partition, O_RDONLY | O_BINARY | O_LARGEFILE);
+if (fd >= 0) {
+partition_found = true;
+qemu_close(fd);
+break;
+}
+}
+
+/* if a working partition on the device was not found */
+if (partition_found == false) {
+error_setg(errp, "Error: Failed to find a working partition on "
+ 
"disc!\n");
+} else {
+DPRINTF("Using %s as optical disc\n", test_partition);
+pstrcpy(bsd_path, MAXPATHLEN, test_partition);
+}
+return partition_found;
+}
+#endif /* defined(__APPLE__) && defined(__MACH__) */
 
 static int hdev_probe_device(const char *filename)
 {
@@ -2115,6 +2156,17 @@

[Qemu-devel] [PATCH v2] ui/cocoa.m: Prevent activation clicks from going to guest

[Programmingkid]

When QEMU is brought to the foreground, the click event that activates QEMU
should not go to the guest. Accidents happen when they do go to the guest
without giving the user a change to handle them. Buttons are clicked accidently.
Windows are closed accidently. Volumes are unmounted accidently. This patch
prevents these accidents from happening. 

Signed-off-by: John Arbuckle 

---
Added code that handles the right mouse button and the other mouse button.

 ui/cocoa.m |   22 ++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 7730d0f..f23f5fd 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -696,6 +696,16 @@ QemuCocoaView *cocoaView;
 mouse_event = true;
 break;
 case NSLeftMouseDown:
+/*
+ * This prevents the click that activates QEMU from being sent to
+ * the guest.
+ */
+if (!isMouseGrabbed && [self screenContainsPoint:p]) {
+[self grabMouse];
+[NSApp sendEvent:event];
+return;
+}
+
 if ([event modifierFlags] & NSCommandKeyMask) {
 buttons |= MOUSE_EVENT_RBUTTON;
 } else {
@@ -704,10 +714,22 @@ QemuCocoaView *cocoaView;
 mouse_event = true;
 break;
 case NSRightMouseDown:
+if (!isMouseGrabbed && [self screenContainsPoint:p]) {
+[self grabMouse];
+[NSApp sendEvent:event];
+return;
+}
+
 buttons |= MOUSE_EVENT_RBUTTON;
 mouse_event = true;
 break;
 case NSOtherMouseDown:
+if (!isMouseGrabbed && [self screenContainsPoint:p]) {
+[self grabMouse];
+[NSApp sendEvent:event];
+return;
+}
+
 buttons |= MOUSE_EVENT_MBUTTON;
 mouse_event = true;
 break;
-- 
1.7.5.4

[Qemu-devel] [PATCH v8] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

Mac OS X can be picky when it comes to allowing the user
to use physical devices in QEMU. Most mounted volumes
appear to be off limits to QEMU. If an issue is detected,
a message is displayed showing the user how to unmount a
volume.

Signed-off-by: John Arbuckle 

---
 block/raw-posix.c |   98 +++--
 1 files changed, 72 insertions(+), 26 deletions(-)

diff --git a/block/raw-posix.c b/block/raw-posix.c
index ccfec1c..d0190c1 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -42,9 +42,8 @@
 #include 
 #include 
 #include 
-//#include 
 #include 
-#endif
+#endif /* (__APPLE__) && (__MACH__) */
 
 #ifdef __sun__
 #define _POSIX_PTHREAD_SEMANTICS 1
@@ -2033,7 +2032,36 @@ kern_return_t GetBSDPath(io_iterator_t mediaIterator, 
char *bsdPath,
 return kernResult;
 }
 
-#endif
+/* Sets up a real cdrom for use in QEMU */
+static bool setup_cdrom(char *bsd_path, Error **errp)
+{
+int index, num_of_test_partitions = 2, fd;
+char test_partition[MAXPATHLEN];
+bool partition_found = false;
+
+/* look for a working partition */
+for (index = 0; index < num_of_test_partitions; index++) {
+snprintf(test_partition, sizeof(test_partition), "%ss%d", bsd_path,
+ 
index);
+fd = qemu_open(test_partition, O_RDONLY | O_BINARY | O_LARGEFILE);
+if (fd >= 0) {
+partition_found = true;
+qemu_close(fd);
+break;
+}
+}
+
+/* if a working partition on the device was not found */
+if (partition_found == false) {
+error_setg(errp, "Error: Failed to find a working partition on "
+ 
"disc!\n");
+} else {
+DPRINTF("Using %s as optical disc\n", test_partition);
+pstrcpy(bsd_path, MAXPATHLEN, test_partition);
+}
+return partition_found;
+}
+#endif /* defined(__APPLE__) && defined(__MACH__) */
 
 static int hdev_probe_device(const char *filename)
 {
@@ -2115,6 +2143,17 @@ static bool hdev_is_sg(BlockDriverState *bs)
 return false;
 }
 
+/* Prints directions on mounting and unmounting a device */
+static void printUnmountingDirections(const char *file_name)
+{
+error_report("Error: If device %s is mounted on the desktop, unmount"
+ " it first before using it in QEMU.\n", 
file_name);
+error_report("Command to unmount device: diskutil unmountDisk %s\n",
+ 
file_name);
+error_report("Command to mount device: diskutil mountDisk %s\n",
+ 
file_name);
+}
+
 static int hdev_open(BlockDriverState *bs, QDict *options, int flags,
  Error **errp)
 {
@@ -2123,32 +2162,32 @@ static int hdev_open(BlockDriverState *bs, QDict 
*options, int flags,
 int ret;
 
 #if defined(__APPLE__) && defined(__MACH__)
-const char *filename = qdict_get_str(options, "filename");
+const char *file_name = qdict_get_str(options, "filename");
 
-if (strstart(filename, "/dev/cdrom", NULL)) {
-kern_return_t kernResult;
+/* If using a real cdrom */
+if (strcmp(file_name, "/dev/cdrom") == 0) {
+char bsd_path[MAXPATHLEN];
 io_iterator_t mediaIterator;
-char bsdPath[ MAXPATHLEN ];
-int fd;
-
-kernResult = FindEjectableCDMedia( &mediaIterator );
-kernResult = GetBSDPath(mediaIterator, bsdPath, sizeof(bsdPath),
-flags);
-if ( bsdPath[ 0 ] != '\0' ) {
-strcat(bsdPath,"s0");
-/* some CDs don't have a partition 0 */
-fd = qemu_open(bsdPath, O_RDONLY | O_BINARY | O_LARGEFILE);
-if (fd < 0) {
-bsdPath[strlen(bsdPath)-1] = '1';
-} else {
-qemu_close(fd);
-}
-filename = bsdPath;
-qdict_put(options, "filename", qstring_from_str(filename));
+FindEjectableCDMedia(&mediaIterator);
+GetBSDPath(mediaIterator, bsd_path, sizeof(bsd_path), flags);
+if (mediaIterator) {
+IOObjectRelease(mediaIterator);
+}
+
+/* If a real optical drive was not found */
+if (bsd_path[0] == '\0') {
+error_setg(errp, "Error: failed to obtain bsd path for optical"
+   " 
drive!\n");
+return -1;
 }
 
-if ( mediaIterator )
-IOObjectRelease( mediaIterator );
+/* If finding a partition on the cdrom disc failed */
+if (setup_cdrom(bsd_path, errp) == false) {
+printUnmountingDirections(bsd_path);
+return -1;
+}
+file_name = bsd_path;
+qdict_put(options, "filename", qstring_from_str(file_name)

[Qemu-devel] QEMU being able to use audio cdroms

[Programmingkid]

Is there any platform where a guest in QEMU can play an audio cd? If not, is 
this a feature that you would allow into QEMU?

[Qemu-devel] [PATCH] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

Mac OS X can be picky when it comes to allowing the user
to use physical devices in QEMU. Most mounted volumes
appear to be off limits to QEMU. If an issue is detected,
a message is displayed showing the user how to unmount a
volume.

Signed-off-by: John Arbuckle 

---
Changed cdromOK variable to cdrom_ok.
Set initial value of cdrom_ok to false.
Moved declaration of cdrom_ok variable to Mac OS X code block.
Replaced printf() calls with error_report().
Changed if (ret < 0) to if (ret != 0).

 block/raw-posix.c |  102 ++---
 1 files changed, 73 insertions(+), 29 deletions(-)

diff --git a/block/raw-posix.c b/block/raw-posix.c
index aec9ec6..3625f35 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -42,9 +42,8 @@
 #include 
 #include 
 #include 
-//#include 
 #include 
-#endif
+#endif /* (__APPLE__) && (__MACH__) */
 
 #ifdef __sun__
 #define _POSIX_PTHREAD_SEMANTICS 1
@@ -1975,9 +1974,9 @@ BlockDriver bdrv_file = {
 /* host device */
 
 #if defined(__APPLE__) && defined(__MACH__)
-static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
-static kern_return_t GetBSDPath( io_iterator_t mediaIterator, char *bsdPath, 
CFIndex maxPathSize );
-
+static kern_return_t FindEjectableCDMedia(io_iterator_t *mediaIterator);
+static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
+CFIndex maxPathSize, int flags);
 kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
 {
 kern_return_t   kernResult;
@@ -2004,7 +2003,8 @@ kern_return_t FindEjectableCDMedia( io_iterator_t 
*mediaIterator )
 return kernResult;
 }
 
-kern_return_t GetBSDPath( io_iterator_t mediaIterator, char *bsdPath, CFIndex 
maxPathSize )
+kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
+ CFIndex maxPathSize, int flags)
 {
 io_object_t nextMedia;
 kern_return_t   kernResult = KERN_FAILURE;
@@ -2017,7 +2017,9 @@ kern_return_t GetBSDPath( io_iterator_t mediaIterator, 
char *bsdPath, CFIndex ma
 if ( bsdPathAsCFString ) {
 size_t devPathLength;
 strcpy( bsdPath, _PATH_DEV );
-strcat( bsdPath, "r" );
+if (flags & BDRV_O_NOCACHE) {
+strcat(bsdPath, "r");
+}
 devPathLength = strlen( bsdPath );
 if ( CFStringGetCString( bsdPathAsCFString, bsdPath + 
devPathLength, maxPathSize - devPathLength, kCFStringEncodingASCII ) ) {
 kernResult = KERN_SUCCESS;
@@ -2030,7 +2032,34 @@ kern_return_t GetBSDPath( io_iterator_t mediaIterator, 
char *bsdPath, CFIndex ma
 return kernResult;
 }
 
-#endif
+/* Sets up a real cdrom for use in QEMU */
+static bool setupCDROM(char *bsdPath)
+{
+int index, numOfTestPartitions = 2, fd;
+char testPartition[MAXPATHLEN];
+bool partitionFound = false;
+
+/* look for a working partition */
+for (index = 0; index < numOfTestPartitions; index++) {
+snprintf(testPartition, sizeof(testPartition), "%ss%d", bsdPath, 
index);
+fd = qemu_open(testPartition, O_RDONLY | O_BINARY | O_LARGEFILE);
+if (fd >= 0) {
+partitionFound = true;
+qemu_close(fd);
+break;
+}
+}
+
+/* if a working partition on the device was not found */
+if (partitionFound == false) {
+error_report("Error: Failed to find a working partition on disc!\n");
+} else {
+DPRINTF("Using %s as optical disc\n", testPartition);
+pstrcpy(bsdPath, MAXPATHLEN, testPartition);
+}
+return partitionFound;
+}
+#endif /* defined(__APPLE__) && defined(__MACH__) */
 
 static int hdev_probe_device(const char *filename)
 {
@@ -2120,32 +2149,31 @@ static int hdev_open(BlockDriverState *bs, QDict 
*options, int flags,
 int ret;
 
 #if defined(__APPLE__) && defined(__MACH__)
+bool cdrom_ok = false;
 const char *filename = qdict_get_str(options, "filename");
 
-if (strstart(filename, "/dev/cdrom", NULL)) {
-kern_return_t kernResult;
-io_iterator_t mediaIterator;
-char bsdPath[ MAXPATHLEN ];
-int fd;
-
-kernResult = FindEjectableCDMedia( &mediaIterator );
-kernResult = GetBSDPath( mediaIterator, bsdPath, sizeof( bsdPath ) );
-
-if ( bsdPath[ 0 ] != '\0' ) {
-strcat(bsdPath,"s0");
-/* some CDs don't have a partition 0 */
-fd = qemu_open(bsdPath, O_RDONLY | O_BINARY | O_LARGEFILE);
-if (fd < 0) {
-bsdPath[strlen(bsdPath)-1] = '1';
+/* If using a physical device */
+if (strstart(filename, "/dev/", NULL)) {
+char bsdPath[MAXPATHLEN];
+
+/* If the physical device is a cdrom */
+if (strcmp(filename, "/dev/cdrom") == 0) {
+io_iterator_t mediaIterator;
+FindEjectableCDMedia(&mediaIterator);
+GetBSDPath(mediaIterator, bsdPath, sizeof(bsdPath), flags);
+ 

Re: [Qemu-devel] [PATCH v6] raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

On Nov 24, 2015, at 9:38 AM, Kevin Wolf wrote:
> 
> 
>> +/* If using a physical device */
>> +if (strstart(filename, "/dev/", NULL)) {
>> +char bsdPath[MAXPATHLEN];
>> +
>> +/* If the physical device is a cdrom */
>> +if (strcmp(filename, "/dev/cdrom") == 0) {
> 
> The original code considered everything that starts in "/dev/cdrom", but
> this one only considers exact matches. Intentional?

Yes. CDROM's are handled differently from other kinds of devices. 

> 
> The outer strstart() check is redundant in this code as it is written.
> I'm not sure what you really wanted to do for the case that starts in
> "/dev/" but is different from "/dev/cdrom", but with this implementation
> nothing happens.
> 
>> +io_iterator_t mediaIterator;
>> +FindEjectableCDMedia(&mediaIterator);
>> +GetBSDPath(mediaIterator, bsdPath, sizeof(bsdPath), flags);
>> +if (bsdPath[0] == '\0') {
>> +printf("Error: failed to obtain bsd path for optical 
>> drive!\n");
> 
> If this is really an error, shouldn't we actually set errp and return
> from the function? And if it's not an error, being silent sounds right.

It is an error. But there is a chance that unmounting the device's volume from
the desktop might fix the problem, so letting the function continue to the 
helpful
error messages would be beneficial to the user. 

>> 
>> +#if defined(__APPLE__) && defined(__MACH__)
>> +/* if a physical device experienced an error while being opened */
>> +if (strncmp(filename, "/dev/", 5) == 0 && (cdromOK == false || ret != 
>> 0)) {
> 
> Using strstart() would probably be more consistent.

I would really prefer to stick with strncmp(). It is ANSI C and very well 
documented.
A search for strstart() did not turn up any documentation on it. 

> 
> I asked in v5 whether ret > 0 was possible (because otherwise the two
> 'if (ret < 0)' blocks could be merged) and you said it was. Now I
> reviewed raw_open_common() and I must say that I can't see how this
> function would ever return anything other than 0 or a negative errno.

It is possible the raw_open_common() function could be changed in the future
to produce positive error numbers. I think checking for anything that isn't zero
is the best thing to do.

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest

[Programmingkid]

On Nov 24, 2015, at 3:56 AM, Peter Maydell wrote:

> On 24 November 2015 at 03:25, Programmingkid  
> wrote:
>> 
>> On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote:
>> 
>>> On 22 November 2015 at 01:43, Programmingkid  
>>> wrote:
>>>> When QEMU is brought to the foreground, the click event that activates QEMU
>>>> should not go to the guest. Accidents happen when they do go to the guest
>>>> without giving the user a change to handle them. Buttons are clicked 
>>>> accidently.
>>>> Windows are closed accidently. Volumes are unmounted accidently. This patch
>>>> prevents these accidents from happening.
>>>> 
>>>> Signed-off-by: John Arbuckle 
>>> 
>>> So, I checked how Parallels behaves (this is my go-to check for
>>> "how should a native OSX VM window behave?"), and it works the
>>> same way QEMU does -- left mouse clicks "click through" so they
>>> both raise the window to the front and have the behaviour
>>> indicated by the guest OS.
>> 
>> But doesn't Parallels allow you to move the mouse pointer before activating 
>> it?
>> QEMU requires the mouse to be grabbed before any movement can take
>> place. That makes moving the mouse pointer out of danger before an activation
>> click impossible.
> 
> I'm not entirely sure what you mean. Parallels doesn't show a separate
> guest mouse pointer generally: where you click the host mouse pointer
> is where the click happens. You can choose where in the guest window you
> want to make the activation-and-clickthrough click.
> 
> Ah, I think I've just worked it out -- when there's no guest OS
> support for absolute mouse positioning (ie you're using an emulated
> mouse rather than emulated tablet for input), the guest mouse pointer
> will just be wherever in the guest window it was left (perhaps even
> underneath the obscuring window), so we will effectively click on that
> point, not on wherever the user actually made the activating click.
> OK, I'm convinced, we should definitely not do that.
> 
> I asked somebody to check VMWare's behaviour as another
> data point. Apparently it doesn't do click-through
> to the guest window, but it doesn't pass through the
> right mouse button either. Your patch only affects leftclicks:
> should we suppress other mouse events too?

Suppressing other mouse events does sound logical. Another patch
will be made to do this.

Re: [Qemu-devel] [OpenBIOS] [Qemu-ppc] CUDA has problems with Mac OS 10.4

[Programmingkid]

On Nov 23, 2015, at 4:00 PM, Mark Cave-Ayland wrote:

> On 22/11/15 17:39, Programmingkid wrote:
> 
>>>>> Hi Alfonso,
>>>>> 
>>>>> Has there been any progress at all as to which extensions may be causing
>>>>> the crashes?
>>>> 
>>>> Remove these extensions from the Extensions folder and Mac OS 9 will boot 
>>>> to the desktop:
>>>> 
>>>> Apple Audio Extension
>>>> Apple Enet
>>>> Multiprocessing folder
>>>> Open Transport aslm modules
>>>> Text Encoding Converter
>>>> 
>>>> Note: I used Cormac's Mac OS 9.2.1 iso file to do my testing.
>>> 
>>> Now this is definitely helpful. Just to confirm that the presence of any
>>> *one* of these modules causes boot to fail?
>> 
>> Yes. That is correct. 
> 
> I've just done some testing here on my 9.2.2 ISO and I've found the
> following:
> 
> - Removing "Apple Audio Extension" appears to prevent some kind of
> corruption which allows MacsBugs to give non-corrupt stack traces
> 
> - The resulting stack trace points at "AINI 8042 05AE Startup ASLM PPC"
> 
> - Further removing "Open Transport ASLM Modules" allows boot to proceed
> nearly all the way except for a hang just before the progress bar
> reaches the end
> 
> - Finally removing "Multiprocessing" allows boot to proceed all the way
> to the desktop
> 
> Alfonso/John can you confirm whether removing these 3 extensions works
> for your images too? If you are able to run the OS 9 installer all the
> way through and manually mount the hd images to remove them by hand
> before the next boot, do you end up with a bootable OS 9 HD image?

It does work for me, but an illegal instruction error took place when the
desktop showed up. I could not do anything after the crash. Mac OS 9 does
hang sometimes earlier in the boot process,  so the above results are not 
consistent. 

My info:
Image: Mac OS 9.2.1 (Cormac's image)
Macsbug 6.6.3
Host: Mac OS 10.6

Re: [Qemu-devel] [OpenBIOS] [Qemu-ppc] CUDA has problems with Mac OS 10.4

[Programmingkid]

On Nov 23, 2015, at 4:00 PM, Mark Cave-Ayland wrote:

> On 22/11/15 17:39, Programmingkid wrote:
> 
>>>>> Hi Alfonso,
>>>>> 
>>>>> Has there been any progress at all as to which extensions may be causing
>>>>> the crashes?
>>>> 
>>>> Remove these extensions from the Extensions folder and Mac OS 9 will boot 
>>>> to the desktop:
>>>> 
>>>> Apple Audio Extension
>>>> Apple Enet
>>>> Multiprocessing folder
>>>> Open Transport aslm modules
>>>> Text Encoding Converter
>>>> 
>>>> Note: I used Cormac's Mac OS 9.2.1 iso file to do my testing.
>>> 
>>> Now this is definitely helpful. Just to confirm that the presence of any
>>> *one* of these modules causes boot to fail?
>> 
>> Yes. That is correct. 
> 
> I've just done some testing here on my 9.2.2 ISO and I've found the
> following:
> 
> - Removing "Apple Audio Extension" appears to prevent some kind of
> corruption which allows MacsBugs to give non-corrupt stack traces
> 
> - The resulting stack trace points at "AINI 8042 05AE Startup ASLM PPC"
> 
> - Further removing "Open Transport ASLM Modules" allows boot to proceed
> nearly all the way except for a hang just before the progress bar
> reaches the end
> 
> - Finally removing "Multiprocessing" allows boot to proceed all the way
> to the desktop
> 
> Alfonso/John can you confirm whether removing these 3 extensions works
> for your images too? If you are able to run the OS 9 installer all the
> way through and manually mount the hd images to remove them by hand
> before the next boot, do you end up with a bootable OS 9 HD image?

Which version of Macsbug are you using? Do you have an 9.2.2 image file
available for download that has macsbug installed? I tried installing Macsbug
6.6.3 into my iso file, but Mac OS 9 always stops booting right before the 
debugger
message is suppose to appear.

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest

[Programmingkid]

On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote:

> On 22 November 2015 at 01:43, Programmingkid  
> wrote:
>> When QEMU is brought to the foreground, the click event that activates QEMU
>> should not go to the guest. Accidents happen when they do go to the guest
>> without giving the user a change to handle them. Buttons are clicked 
>> accidently.
>> Windows are closed accidently. Volumes are unmounted accidently. This patch
>> prevents these accidents from happening.
>> 
>> Signed-off-by: John Arbuckle 
> 
> So, I checked how Parallels behaves (this is my go-to check for
> "how should a native OSX VM window behave?"), and it works the
> same way QEMU does -- left mouse clicks "click through" so they
> both raise the window to the front and have the behaviour
> indicated by the guest OS.

But doesn't Parallels allow you to move the mouse pointer before activating it? 
QEMU requires the mouse to be grabbed before any movement can take 
place. That makes moving the mouse pointer out of danger before an activation
click impossible.

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest

[Programmingkid]

On Nov 23, 2015, at 11:06 AM, Peter Maydell wrote:

> On 22 November 2015 at 01:43, Programmingkid  
> wrote:
>> When QEMU is brought to the foreground, the click event that activates QEMU
>> should not go to the guest. Accidents happen when they do go to the guest
>> without giving the user a change to handle them. Buttons are clicked 
>> accidently.
>> Windows are closed accidently. Volumes are unmounted accidently. This patch
>> prevents these accidents from happening.
>> 
>> Signed-off-by: John Arbuckle 
> 
> So, I checked how Parallels behaves (this is my go-to check for
> "how should a native OSX VM window behave?"), and it works the
> same way QEMU does -- left mouse clicks "click through" so they
> both raise the window to the front and have the behaviour
> indicated by the guest OS.

What if we were better than Parallels? Apple's own human interface guidelines 
state that the
activation click should not make any changes to the application.

Re: [Qemu-devel] [OpenBIOS] [Qemu-ppc] CUDA has problems with Mac OS 10.4

[Programmingkid]

On Nov 22, 2015, at 6:58 AM, Mark Cave-Ayland wrote:

> On 21/11/15 22:59, Programmingkid wrote:
> 
>> On Nov 21, 2015, at 7:32 AM, Mark Cave-Ayland wrote:
>> 
>>> On 20/11/15 17:06, Alfonso Gamboa wrote:
>>> 
>>>> booting into MacOS9 with qemu to the Desktop is now possible, see:
>>>> 
>>>> http://www.emaculation.com/forum/viewtopic.php?f=34&t=7047&start=250
>>>> 
>>>> Some issues,  remain,  certain extensions crash on boot.
>>> 
>>> Hi Alfonso,
>>> 
>>> Has there been any progress at all as to which extensions may be causing
>>> the crashes?
>> 
>> Remove these extensions from the Extensions folder and Mac OS 9 will boot to 
>> the desktop:
>> 
>> Apple Audio Extension
>> Apple Enet
>> Multiprocessing folder
>> Open Transport aslm modules
>> Text Encoding Converter
>> 
>> Note: I used Cormac's Mac OS 9.2.1 iso file to do my testing.
> 
> Now this is definitely helpful. Just to confirm that the presence of any
> *one* of these modules causes boot to fail?

Yes. That is correct. 

[Qemu-devel] [PATCH] ui/cocoa.m: Prevent activation clicks from going to guest

[Programmingkid]

When QEMU is brought to the foreground, the click event that activates QEMU
should not go to the guest. Accidents happen when they do go to the guest
without giving the user a change to handle them. Buttons are clicked accidently.
Windows are closed accidently. Volumes are unmounted accidently. This patch
prevents these accidents from happening. 

Signed-off-by: John Arbuckle 

---
 ui/cocoa.m |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 1554331..b75c01e 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -669,6 +669,16 @@ QemuCocoaView *cocoaView;
 mouse_event = true;
 break;
 case NSLeftMouseDown:
+/*
+ * This prevents the click that activates QEMU from being sent to
+ * the guest.
+ */
+if (!isMouseGrabbed && [self screenContainsPoint:p]) {
+[self grabMouse];
+[NSApp sendEvent:event];
+return;
+}
+
 if ([event modifierFlags] & NSCommandKeyMask) {
 buttons |= MOUSE_EVENT_RBUTTON;
 } else {
-- 
1.7.5.4

Re: [Qemu-devel] [OpenBIOS] [Qemu-ppc] CUDA has problems with Mac OS 10.4

[Programmingkid]

On Nov 21, 2015, at 7:32 AM, Mark Cave-Ayland wrote:

> On 20/11/15 17:06, Alfonso Gamboa wrote:
> 
>> booting into MacOS9 with qemu to the Desktop is now possible, see:
>> 
>> http://www.emaculation.com/forum/viewtopic.php?f=34&t=7047&start=250
>> 
>> Some issues,  remain,  certain extensions crash on boot.
> 
> Hi Alfonso,
> 
> Has there been any progress at all as to which extensions may be causing
> the crashes?

Remove these extensions from the Extensions folder and Mac OS 9 will boot to 
the desktop:

Apple Audio Extension
Apple Enet
Multiprocessing folder
Open Transport aslm modules
Text Encoding Converter

Note: I used Cormac's Mac OS 9.2.1 iso file to do my testing.

Re: [Qemu-devel] [OpenBIOS] [Qemu-ppc] CUDA has problems with Mac OS 10.4

[Programmingkid]

On Nov 21, 2015, at 7:32 AM, Mark Cave-Ayland wrote:

> On 20/11/15 17:06, Alfonso Gamboa wrote:
> 
>> booting into MacOS9 with qemu to the Desktop is now possible, see:
>> 
>> http://www.emaculation.com/forum/viewtopic.php?f=34&t=7047&start=250
>> 
>> Some issues,  remain,  certain extensions crash on boot.
> 
> Hi Alfonso,
> 
> Has there been any progress at all as to which extensions may be causing
> the crashes?

Trying to find that out is going to be hard. The extension manager does not 
appear when the space bar is held down.

Re: [Qemu-devel] [PATCH v5] raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

On Nov 20, 2015, at 11:26 AM, Kevin Wolf wrote:

> Am 27.07.2015 um 19:05 hat Programmingkid geschrieben:
>> Mac OS X can be picky when it comes to allowing the user to use physical
>> devices
>> in QEMU. Most mounted volumes appear to be off limits to QEMU. If an issue is
>> detected, a message is displayed showing the user how to unmount a volume.
>> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> Removed changes to GetBSDPath() to a separate patch.
>> This patch now depends on the GetBSDPath patch.
> 
> Unfortunately, this patch was sent as HTML, so git am doesn't accept it.
> I tried to manually get something working out of it, but I failed.
> Possibly there are actual merge conflicts, too (even going back to
> master@{2015-07-27}), but in any case I couldn't apply this.
> 
> Can you please rebase and send as a plain text patch that applies to
> current master?

Sorry for the HTML. This patch has been fixed and sent in.

> 
>> @@ -2156,7 +2180,21 @@ static int hdev_open(BlockDriverState *bs, QDict
>> *options, int flags,
>> if (local_err) {
>> error_propagate(errp, local_err);
>> }
>> -return ret;
>> +}
>> +
>> +#if defined(__APPLE__) && defined(__MACH__)
>> +/* if a physical device experienced an error while being opened */
>> +if (strncmp(filename, "/dev/", 5) == 0 && (cdromOK == false || ret != 
>> 0))
>> {
>> +printf("If device %s is mounted on the desktop, unmount it"
>> +" first before using it in QEMU.\n", filename);
>> +printf("Command to unmount device: diskutil unmountDisk %s\n",
>> +
>> filename);
>> +printf("Command to mount device: diskutil mountDisk %s\n", 
>> filename);
>> +}
>> +#endif /* defined(__APPLE__) && defined(__MACH__) */
>> +
>> +if (ret < 0) {
>> +   return ret;
>> }
> 
> Why don't you simply include the #ifdef block in the first if (ret < 0)?
> Or does ret > 0 happen and the message must be displayed for it?

ret > 0 could happen and a message should be displayed for it. 

[Qemu-devel] [PATCH v6] raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

Mac OS X can be picky when it comes to allowing the user
to use physical devices in QEMU. Most mounted volumes
appear to be off limits to QEMU. If an issue is detected,
a message is displayed showing the user how to unmount a
volume.

Signed-off-by: John Arbuckle 

---
This patch depends on the GetBSDPath patch.

 block/raw-posix.c |   90 +---
 1 files changed, 64 insertions(+), 26 deletions(-)

diff --git a/block/raw-posix.c b/block/raw-posix.c
index ccfec1c..28bce71 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -42,9 +42,8 @@
 #include 
 #include 
 #include 
-//#include 
 #include 
-#endif
+#endif /* (__APPLE__) && (__MACH__) */
 
 #ifdef __sun__
 #define _POSIX_PTHREAD_SEMANTICS 1
@@ -1975,7 +1974,7 @@ BlockDriver bdrv_file = {
 /* host device */
 
 #if defined(__APPLE__) && defined(__MACH__)
-static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
+static kern_return_t FindEjectableCDMedia(io_iterator_t *mediaIterator);
 static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
 CFIndex maxPathSize, int flags);
 kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
@@ -2033,7 +2032,34 @@ kern_return_t GetBSDPath(io_iterator_t mediaIterator, 
char *bsdPath,
 return kernResult;
 }
 
-#endif
+/* Sets up a real cdrom for use in QEMU */
+static bool setupCDROM(char *bsdPath)
+{
+int index, numOfTestPartitions = 2, fd;
+char testPartition[MAXPATHLEN];
+bool partitionFound = false;
+
+/* look for a working partition */
+for (index = 0; index < numOfTestPartitions; index++) {
+snprintf(testPartition, sizeof(testPartition), "%ss%d", bsdPath, 
index);
+fd = qemu_open(testPartition, O_RDONLY | O_BINARY | O_LARGEFILE);
+if (fd >= 0) {
+partitionFound = true;
+qemu_close(fd);
+break;
+}
+}
+
+/* if a working partition on the device was not found */
+if (partitionFound == false) {
+printf("Error: Failed to find a working partition on disc!\n");
+} else {
+DPRINTF("Using %s as optical disc\n", testPartition);
+pstrcpy(bsdPath, MAXPATHLEN, testPartition);
+}
+return partitionFound;
+}
+#endif /* defined(__APPLE__) && defined(__MACH__) */
 
 static int hdev_probe_device(const char *filename)
 {
@@ -2121,34 +2147,32 @@ static int hdev_open(BlockDriverState *bs, QDict 
*options, int flags,
 BDRVRawState *s = bs->opaque;
 Error *local_err = NULL;
 int ret;
+bool cdromOK = true;
 
 #if defined(__APPLE__) && defined(__MACH__)
 const char *filename = qdict_get_str(options, "filename");
-
-if (strstart(filename, "/dev/cdrom", NULL)) {
-kern_return_t kernResult;
-io_iterator_t mediaIterator;
-char bsdPath[ MAXPATHLEN ];
-int fd;
-
-kernResult = FindEjectableCDMedia( &mediaIterator );
-kernResult = GetBSDPath(mediaIterator, bsdPath, sizeof(bsdPath),
-flags);
-if ( bsdPath[ 0 ] != '\0' ) {
-strcat(bsdPath,"s0");
-/* some CDs don't have a partition 0 */
-fd = qemu_open(bsdPath, O_RDONLY | O_BINARY | O_LARGEFILE);
-if (fd < 0) {
-bsdPath[strlen(bsdPath)-1] = '1';
+ 
+/* If using a physical device */
+if (strstart(filename, "/dev/", NULL)) {
+char bsdPath[MAXPATHLEN];
+
+/* If the physical device is a cdrom */
+if (strcmp(filename, "/dev/cdrom") == 0) {
+io_iterator_t mediaIterator;
+FindEjectableCDMedia(&mediaIterator);
+GetBSDPath(mediaIterator, bsdPath, sizeof(bsdPath), flags);
+if (bsdPath[0] == '\0') {
+printf("Error: failed to obtain bsd path for optical 
drive!\n");
 } else {
-qemu_close(fd);
+cdromOK = setupCDROM(bsdPath);
+filename = bsdPath;
+}
+
+if (mediaIterator) {
+IOObjectRelease(mediaIterator);
 }
-filename = bsdPath;
 qdict_put(options, "filename", qstring_from_str(filename));
 }
-
-if ( mediaIterator )
-IOObjectRelease( mediaIterator );
 }
 #endif
 
@@ -2159,7 +2183,21 @@ static int hdev_open(BlockDriverState *bs, QDict 
*options, int flags,
 if (local_err) {
 error_propagate(errp, local_err);
 }
-return ret;
+}
+
+#if defined(__APPLE__) && defined(__MACH__)
+/* if a physical device experienced an error while being opened */
+if (strncmp(filename, "/dev/", 5) == 0 && (cdromOK == false || ret != 0)) {
+printf("\nError: If device %s is mounted on the desktop, unmount it"
+" first before using it in QEMU.\n", filename);
+printf("Command to unmount device: diskutil unmountDisk %s\n",

[Qemu-devel] [PATCH v2] raw-posix.c: Make GetBSDPath() handle caching options

[Programmingkid]

Add support for caching options that can be specified from
the command line. 

Signed-off-by: John Arbuckle 

---
Only location of code has been changed.

 block/raw-posix.c |   15 +--
 1 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/block/raw-posix.c b/block/raw-posix.c
index aec9ec6..ccfec1c 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -1976,8 +1976,8 @@ BlockDriver bdrv_file = {
 
 #if defined(__APPLE__) && defined(__MACH__)
 static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
-static kern_return_t GetBSDPath( io_iterator_t mediaIterator, char *bsdPath, 
CFIndex maxPathSize );
-
+static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
+CFIndex maxPathSize, int flags);
 kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
 {
 kern_return_t   kernResult;
@@ -2004,7 +2004,8 @@ kern_return_t FindEjectableCDMedia( io_iterator_t 
*mediaIterator )
 return kernResult;
 }
 
-kern_return_t GetBSDPath( io_iterator_t mediaIterator, char *bsdPath, CFIndex 
maxPathSize )
+kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
+ CFIndex maxPathSize, int flags)
 {
 io_object_t nextMedia;
 kern_return_t   kernResult = KERN_FAILURE;
@@ -2017,7 +2018,9 @@ kern_return_t GetBSDPath( io_iterator_t mediaIterator, 
char *bsdPath, CFIndex ma
 if ( bsdPathAsCFString ) {
 size_t devPathLength;
 strcpy( bsdPath, _PATH_DEV );
-strcat( bsdPath, "r" );
+if (flags & BDRV_O_NOCACHE) {
+strcat(bsdPath, "r");
+}
 devPathLength = strlen( bsdPath );
 if ( CFStringGetCString( bsdPathAsCFString, bsdPath + 
devPathLength, maxPathSize - devPathLength, kCFStringEncodingASCII ) ) {
 kernResult = KERN_SUCCESS;
@@ -2129,8 +2132,8 @@ static int hdev_open(BlockDriverState *bs, QDict 
*options, int flags,
 int fd;
 
 kernResult = FindEjectableCDMedia( &mediaIterator );
-kernResult = GetBSDPath( mediaIterator, bsdPath, sizeof( bsdPath ) );
-
+kernResult = GetBSDPath(mediaIterator, bsdPath, sizeof(bsdPath),
+flags);
 if ( bsdPath[ 0 ] != '\0' ) {
 strcat(bsdPath,"s0");
 /* some CDs don't have a partition 0 */
-- 
1.7.5.4

Re: [Qemu-devel] [Qemu-ppc] [OpenBIOS] CUDA has problems with Mac OS 10.4

[Programmingkid]

On Nov 20, 2015, at 8:39 AM, BALATON Zoltan wrote:

> On Thu, 19 Nov 2015, Segher Boessenkool wrote:
>> Some mac99/pmu99 hardware has an ADB keyboard, fwiw (tibook, for example).
>> The do have built-in USB; that, and being newworld, are not directly
>> related things.
> 
> Maybe, but the PowerMac3,1 we are trying to emulate here does not have ADB 
> AFAIK. Although qemu's mac99 is not a real machine now we should move to 
> being closer to some existing hardware if we want OSes written for that 
> hardware to run.

I use to have the same belief until Mark set me straight. We are only making an 
emulator of a new world Mac, not a simulator of a PowerMac3,1. This means we 
might be able to get away with not exactly mirroring a real Mac. The fact that 
Mac OS 9 can boot up at all does give me hope we are on the right path.

[Qemu-devel] [Qemu-ppc] [PATCH for-2.5] mac_dbdma: always initialize channel field in DBDMA_channel

[Programmingkid]

On Nov 12, 2015, at 11:04 PM, qemu-ppc-requ...@nongnu.org wrote:

> Message: 3
> Date: Thu, 12 Nov 2015 22:24:08 +0100
> From: Herv? Poussineau 
> To: qemu-devel@nongnu.org
> Cc: "open list:Old World" , Herv? Poussineau
>   
> Subject: [Qemu-ppc] [PATCH for-2.5] mac_dbdma: always initialize
>   channel field in DBDMA_channel
> Message-ID: <1447363448-20405-1-git-send-email-hpous...@reactos.org>
> Content-Type: text/plain; charset=UTF-8
> 
> dbdma_from_ch() uses channel field to return the right DBDMA object.
> Previous code was working if guest OS was only using registered DMA channels.
> However, it lead to QEMU crashes if guest OS was using unregistered DMA 
> channels.
> 
> Signed-off-by: Herv? Poussineau 
> ---
> hw/misc/macio/mac_dbdma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/misc/macio/mac_dbdma.c b/hw/misc/macio/mac_dbdma.c
> index 779683c..5ee8f02 100644
> --- a/hw/misc/macio/mac_dbdma.c
> +++ b/hw/misc/macio/mac_dbdma.c
> @@ -557,7 +557,6 @@ void DBDMA_register_channel(void *dbdma, int nchan, 
> qemu_irq irq,
> DBDMA_DPRINTF("DBDMA_register_channel 0x%x\n", nchan);
> 
> ch->irq = irq;
> -ch->channel = nchan;
> ch->rw = rw;
> ch->flush = flush;
> ch->io.opaque = opaque;
> @@ -753,6 +752,7 @@ void* DBDMA_init (MemoryRegion **dbdma_mem)
> for (i = 0; i < DBDMA_CHANNELS; i++) {
> DBDMA_io *io = &s->channels[i].io;
> qemu_iovec_init(&io->iov, 1);
> +s->channels[i].channel = i;
> }
> 
> memory_region_init_io(&s->mem, NULL, &dbdma_ops, s, "dbdma", 0x1000);
> -- 
> 2.1.4

What operating system(s) did you use to test this patch out?

Re: [Qemu-devel] [OpenBIOS] CUDA has problems with Mac OS 10.4

[Programmingkid]

On Nov 11, 2015, at 6:14 PM, BALATON Zoltan wrote:

> On Wed, 11 Nov 2015, Programmingkid wrote:
>> On Nov 11, 2015, at 4:32 PM, Andreas Tobler wrote:
>>>> It looks like you are saying you wish to keep the CUDA device. Mac OS 9 is 
>>>> most
>>>> likely hard coded to expect via-pmu instead of via-cuda on the mac99 
>>>> target.
>>>> Moving on to via-pmu might make QEMU more compatible with Mac OS 9.
>>>> I will still try your patches. Do you have a repo that I could just clone? 
>>>> It is a
>>>> lot less error prone than patches.
>>> 
>>> I'd like to keep the CUDA too, FreeBSD PowerPC (32-bit) relies on it. 
>>> Unfortunately it still doesn't work ... but hope is still here ;)
>> 
>> On a new world Mac? I'm thinking a mistake has been made. Maybe you mean 
>> via-pmu? According to FreeBSD's website all Macintoshes with a built-in USB 
>> port are supported. This would only mean new world Macs and they only have a 
>> via-pmu - no cuda device.
> 
> I think you are right that mac99 should have via-pmu instead of cuda but it 
> is not as simple as renaming it in the device tree because it is a different 
> chip which we have no emulation for so first an emulation should be written. 
> It is probably similar enough to cuda so using cuda instead works as long as 
> the OS in only using the main functions. It is also hard to find a 
> documentation on how via-pmu should behave. I've only found this:
> 
> http://mcosre.sourceforge.net/docs/apple_io.html
> 
> which is not very clear or detailed. The only hint from it was that pmu99 
> uses gpio which I've seen OS-es try to access but I don't know anything on 
> that or what should be emulated for it.

Thank you very much for this information. A quick check of PearPC shows it also 
uses CUDA, so we can't copy any code for via-pmu.

> 
>>> Mark, is your complete qemu patch available somewhere? Then I could test 
>>> 32-bit PowerPC on FreeBSD which still hangs on adb... up to now.
>> 
>> I'm thinking removing ADB support would fix this problem. Most real new 
>> world Macs have no ADB support.
> 
> This may be a good idea to match the hardware we are trying to emulate better 
> but some OSes may depend on ADB for now. I've noticed Finnix had no keyboard 
> in debug mode without ADB (which may be a bug in Finnix, I could not verify 
> if it works on real hardware or has the same problem there).

Interesting. Did you use "-usb -device usb-keyboard" to enable usb support in 
QEMU when running Finnix? 

Re: [Qemu-devel] [OpenBIOS] CUDA has problems with Mac OS 10.4

[Programmingkid]

On Nov 11, 2015, at 6:05 PM, Mark Cave-Ayland wrote:

> On 11/11/15 21:32, Andreas Tobler wrote:
> 
>> On 11.11.15 19:55, Programmingkid wrote:
>>> 
>>> On Nov 11, 2015, at 12:54 PM, Mark Cave-Ayland wrote:
>>> 
>>>> On 11/11/15 15:15, Programmingkid wrote:
>>>> 
>>>>> I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my
>>>>> Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA
>>>>> problem. I did use the mac99 target. Here is the error message:
>>>>> 
>>>>> panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION
>>>>> TYPE AND ERROR
>>>>> 
>>>>> This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d
>>>>> -cdrom ~/tiger.iso  -prom-env boot-args=-v -usb -M mac99
>>>>> 
>>>>> I think there is still something wrong with CUDA. But we might not
>>>>> have to "fix" it. When we use the mac99 target, the PowerMac3,1
>>>>> Macintosh system is what we are trying to emulate. My sources
>>>>> indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is
>>>>> used for ADB communications. Using it only on the BeigeG3 target
>>>>> makes sense.
>>>>> 
>>>>> My sources for the PowerMac3,1 system is this link:
>>>>> http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp.html
>>>>> 
>>>>> 
>>>>> and this device tree:
>>>>> 
>>>>> PowerMac G4 device tree
>>>>> 
>>>>> ff839ab8: /cpus
>>>>> ff839ce8:   /PowerPC,G4@0
>>>>> ff83a060: /l2-cache
>>>>> ff83ab58: /chosen
>>>>> ff83ace8: /memory@0
>>>>> ff83af00: /openprom
>>>>> ff83b008:   /client-services
>>>>> ff83c1a8: /rom@ff80
>>>>> ff83c330:   /boot-rom@fff0
>>>>> ff83c4a8:   /macos
>>>>> ff83c528: /options
>>>>> ff83c5a8: /aliases
>>>>> ff83cec8: /packages
>>>>> ff83cf30:   /deblocker
>>>>> ff83d798:   /disk-label
>>>>> ff83e198:   /obp-tftp
>>>>> ff8439f0:   /mac-parts
>>>>> ff844850:   /mac-files
>>>>> ff847540:   /hfs-plus-files
>>>>> ff84c1c8:   /fat-files
>>>>> ff84def8:   /iso-9660-files
>>>>> ff84eb00:   /bootinfo-loader
>>>>> ff8507a0:   /xcoff-loader
>>>>> ff8511b8:   /pe-loader
>>>>> ff851b90:   /elf-loader
>>>>> ff8531c0:   /usb-hid-class
>>>>> ff8554d8:   /usb-ms-class
>>>>> ff8576a8:   /sbp2-disk
>>>>> ff858ac0:   /ata-disk
>>>>> ff859cd8:   /atapi-disk
>>>>> ff85b348:   /bootpath-search
>>>>> ff861b68:   /terminal-emulator
>>>>> ff861c00: /psuedo-hid
>>>>> ff861c88:   /keyboard
>>>>> ff862308:   /mouse
>>>>> ff862820: /multiboot
>>>>> ff86e7f0: /diagnostics
>>>>> ff86e858: /tools-node
>>>>> ff8704b8: /rtas
>>>>> ff8706b8: /nvram@fff04000
>>>>> ff871180: /uni-n@f800
>>>>> ff8713c8:   /i2c@f8001000
>>>>> ff871b10: /cereal
>>>>> ff8721c0: /pci@f000
>>>>> ff898cd0:   /uni-north-agp@b
>>>>> ff898f40:   /ATY,Rage128Ps@10
>>>>> ff873268: /pci@f200
>>>>> ff8742d8:   /pci-bridge@d
>>>>> ff876368: /mac-io@7
>>>>> ff8773a0:   /interrupt-controller@4
>>>>> ff877548:   /gpio@50
>>>>> ff877630: /extint-gpio1
>>>>> ff8777c8: /programmer-switch
>>>>> ff877900:   /escc-legacy@12000
>>>>> ff877af8: /ch-a@12004
>>>>> ff877c78: /ch-b@12000
>>>>> ff877df8:   /escc@13000
>>>>> ff878000: /ch-a@13020
>>>>> ff8789a8: /ch-b@13000
>>>>> ff8792c0:   /davbus@14000
>>>>> ff879540: /sound
>>>>> ff879c40:   /timer@15000
>>>>> ff879da8:   /via-pmu@16000
>>>>> ff87ccf0: /rtc
>>>>> ff87d3e0: /power-mgt
>>>>> ff8bf378:   /usb-power-mgt
>>>>> ff87d648:   /i2c@18000
>>>>> ff87ded8: /cereal
>>>>

Re: [Qemu-devel] [OpenBIOS] CUDA has problems with Mac OS 10.4

[Programmingkid]

On Nov 11, 2015, at 6:05 PM, Mark Cave-Ayland wrote:

> On 11/11/15 21:32, Andreas Tobler wrote:
> 
>> On 11.11.15 19:55, Programmingkid wrote:
>>> 
>>> On Nov 11, 2015, at 12:54 PM, Mark Cave-Ayland wrote:
>>> 
>>>> On 11/11/15 15:15, Programmingkid wrote:
>>>> 
>>>>> I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my
>>>>> Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA
>>>>> problem. I did use the mac99 target. Here is the error message:
>>>>> 
>>>>> panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION
>>>>> TYPE AND ERROR
>>>>> 
>>>>> This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d
>>>>> -cdrom ~/tiger.iso  -prom-env boot-args=-v -usb -M mac99
>>>>> 
>>>>> I think there is still something wrong with CUDA. But we might not
>>>>> have to "fix" it. When we use the mac99 target, the PowerMac3,1
>>>>> Macintosh system is what we are trying to emulate. My sources
>>>>> indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is
>>>>> used for ADB communications. Using it only on the BeigeG3 target
>>>>> makes sense.
>>>>> 
>>>>> My sources for the PowerMac3,1 system is this link:
>>>>> http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp.html
>>>>> 
>>>>> 
>>>>> and this device tree:
>>>>> 
>>>>> PowerMac G4 device tree
>>>>> 
>>>>> ff839ab8: /cpus
>>>>> ff839ce8:   /PowerPC,G4@0
>>>>> ff83a060: /l2-cache
>>>>> ff83ab58: /chosen
>>>>> ff83ace8: /memory@0
>>>>> ff83af00: /openprom
>>>>> ff83b008:   /client-services
>>>>> ff83c1a8: /rom@ff80
>>>>> ff83c330:   /boot-rom@fff0
>>>>> ff83c4a8:   /macos
>>>>> ff83c528: /options
>>>>> ff83c5a8: /aliases
>>>>> ff83cec8: /packages
>>>>> ff83cf30:   /deblocker
>>>>> ff83d798:   /disk-label
>>>>> ff83e198:   /obp-tftp
>>>>> ff8439f0:   /mac-parts
>>>>> ff844850:   /mac-files
>>>>> ff847540:   /hfs-plus-files
>>>>> ff84c1c8:   /fat-files
>>>>> ff84def8:   /iso-9660-files
>>>>> ff84eb00:   /bootinfo-loader
>>>>> ff8507a0:   /xcoff-loader
>>>>> ff8511b8:   /pe-loader
>>>>> ff851b90:   /elf-loader
>>>>> ff8531c0:   /usb-hid-class
>>>>> ff8554d8:   /usb-ms-class
>>>>> ff8576a8:   /sbp2-disk
>>>>> ff858ac0:   /ata-disk
>>>>> ff859cd8:   /atapi-disk
>>>>> ff85b348:   /bootpath-search
>>>>> ff861b68:   /terminal-emulator
>>>>> ff861c00: /psuedo-hid
>>>>> ff861c88:   /keyboard
>>>>> ff862308:   /mouse
>>>>> ff862820: /multiboot
>>>>> ff86e7f0: /diagnostics
>>>>> ff86e858: /tools-node
>>>>> ff8704b8: /rtas
>>>>> ff8706b8: /nvram@fff04000
>>>>> ff871180: /uni-n@f800
>>>>> ff8713c8:   /i2c@f8001000
>>>>> ff871b10: /cereal
>>>>> ff8721c0: /pci@f000
>>>>> ff898cd0:   /uni-north-agp@b
>>>>> ff898f40:   /ATY,Rage128Ps@10
>>>>> ff873268: /pci@f200
>>>>> ff8742d8:   /pci-bridge@d
>>>>> ff876368: /mac-io@7
>>>>> ff8773a0:   /interrupt-controller@4
>>>>> ff877548:   /gpio@50
>>>>> ff877630: /extint-gpio1
>>>>> ff8777c8: /programmer-switch
>>>>> ff877900:   /escc-legacy@12000
>>>>> ff877af8: /ch-a@12004
>>>>> ff877c78: /ch-b@12000
>>>>> ff877df8:   /escc@13000
>>>>> ff878000: /ch-a@13020
>>>>> ff8789a8: /ch-b@13000
>>>>> ff8792c0:   /davbus@14000
>>>>> ff879540: /sound
>>>>> ff879c40:   /timer@15000
>>>>> ff879da8:   /via-pmu@16000
>>>>> ff87ccf0: /rtc
>>>>> ff87d3e0: /power-mgt
>>>>> ff8bf378:   /usb-power-mgt
>>>>> ff87d648:   /i2c@18000
>>>>> ff87ded8: /cereal
>>>>

Re: [Qemu-devel] [OpenBIOS] CUDA has problems with Mac OS 10.4

[Programmingkid]

On Nov 11, 2015, at 4:32 PM, Andreas Tobler wrote:

> On 11.11.15 19:55, Programmingkid wrote:
>> 
>> On Nov 11, 2015, at 12:54 PM, Mark Cave-Ayland wrote:
>> 
>>> On 11/11/15 15:15, Programmingkid wrote:
>>> 
>>>> I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac 
>>>> OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I 
>>>> did use the mac99 target. Here is the error message:
>>>> 
>>>> panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND 
>>>> ERROR
>>>> 
>>>> This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom 
>>>> ~/tiger.iso  -prom-env boot-args=-v -usb -M mac99
>>>> 
>>>> I think there is still something wrong with CUDA. But we might not have to 
>>>> "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system 
>>>> is what we are trying to emulate. My sources indicate that the PowerMac3,1 
>>>> doesn't have a CUDA chip. This chip is used for ADB communications. Using 
>>>> it only on the BeigeG3 target makes sense.
>>>> 
>>>> My sources for the PowerMac3,1 system is this link: 
>>>> http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp.html
>>>> 
>>>> and this device tree:
>>>> 
>>>> PowerMac G4 device tree
>>>> 
>>>> ff839ab8: /cpus
>>>> ff839ce8:   /PowerPC,G4@0
>>>> ff83a060: /l2-cache
>>>> ff83ab58: /chosen
>>>> ff83ace8: /memory@0
>>>> ff83af00: /openprom
>>>> ff83b008:   /client-services
>>>> ff83c1a8: /rom@ff80
>>>> ff83c330:   /boot-rom@fff0
>>>> ff83c4a8:   /macos
>>>> ff83c528: /options
>>>> ff83c5a8: /aliases
>>>> ff83cec8: /packages
>>>> ff83cf30:   /deblocker
>>>> ff83d798:   /disk-label
>>>> ff83e198:   /obp-tftp
>>>> ff8439f0:   /mac-parts
>>>> ff844850:   /mac-files
>>>> ff847540:   /hfs-plus-files
>>>> ff84c1c8:   /fat-files
>>>> ff84def8:   /iso-9660-files
>>>> ff84eb00:   /bootinfo-loader
>>>> ff8507a0:   /xcoff-loader
>>>> ff8511b8:   /pe-loader
>>>> ff851b90:   /elf-loader
>>>> ff8531c0:   /usb-hid-class
>>>> ff8554d8:   /usb-ms-class
>>>> ff8576a8:   /sbp2-disk
>>>> ff858ac0:   /ata-disk
>>>> ff859cd8:   /atapi-disk
>>>> ff85b348:   /bootpath-search
>>>> ff861b68:   /terminal-emulator
>>>> ff861c00: /psuedo-hid
>>>> ff861c88:   /keyboard
>>>> ff862308:   /mouse
>>>> ff862820: /multiboot
>>>> ff86e7f0: /diagnostics
>>>> ff86e858: /tools-node
>>>> ff8704b8: /rtas
>>>> ff8706b8: /nvram@fff04000
>>>> ff871180: /uni-n@f800
>>>> ff8713c8:   /i2c@f8001000
>>>> ff871b10: /cereal
>>>> ff8721c0: /pci@f000
>>>> ff898cd0:   /uni-north-agp@b
>>>> ff898f40:   /ATY,Rage128Ps@10
>>>> ff873268: /pci@f200
>>>> ff8742d8:   /pci-bridge@d
>>>> ff876368: /mac-io@7
>>>> ff8773a0:   /interrupt-controller@4
>>>> ff877548:   /gpio@50
>>>> ff877630: /extint-gpio1
>>>> ff8777c8: /programmer-switch
>>>> ff877900:   /escc-legacy@12000
>>>> ff877af8: /ch-a@12004
>>>> ff877c78: /ch-b@12000
>>>> ff877df8:   /escc@13000
>>>> ff878000: /ch-a@13020
>>>> ff8789a8: /ch-b@13000
>>>> ff8792c0:   /davbus@14000
>>>> ff879540: /sound
>>>> ff879c40:   /timer@15000
>>>> ff879da8:   /via-pmu@16000
>>>> ff87ccf0: /rtc
>>>> ff87d3e0: /power-mgt
>>>> ff8bf378:   /usb-power-mgt
>>>> ff87d648:   /i2c@18000
>>>> ff87ded8: /cereal
>>>> ff87e5a0:   /ata-4@1f000
>>>> ff880318: /disk
>>>> ff8809e8:   /ata-3@2
>>>> ff882760: /disk
>>>> ff882da8:   /ata-3@21000
>>>> ff884b20: /disk
>>>> ff8864c8: /ethernet@4
>>>> ff888690: /usb@8
>>>> ff88dd50: /usb@9
>>>> ff8be3f0:   /hub@1
>>>> ff8be580: /keyboard@1
>>>> 

Re: [Qemu-devel] CUDA has problems with Mac OS 10.4

[Programmingkid]

On Nov 11, 2015, at 12:54 PM, Mark Cave-Ayland wrote:

> On 11/11/15 15:15, Programmingkid wrote:
> 
>> I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 
>> 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did 
>> use the mac99 target. Here is the error message: 
>> 
>> panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND 
>> ERROR
>> 
>> This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom 
>> ~/tiger.iso  -prom-env boot-args=-v -usb -M mac99
>> 
>> I think there is still something wrong with CUDA. But we might not have to 
>> "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is 
>> what we are trying to emulate. My sources indicate that the PowerMac3,1 
>> doesn't have a CUDA chip. This chip is used for ADB communications. Using it 
>> only on the BeigeG3 target makes sense. 
>> 
>> My sources for the PowerMac3,1 system is this link: 
>> http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp.html
>> 
>> and this device tree:
>> 
>> PowerMac G4 device tree
>> 
>> ff839ab8: /cpus
>> ff839ce8:   /PowerPC,G4@0
>> ff83a060: /l2-cache
>> ff83ab58: /chosen
>> ff83ace8: /memory@0
>> ff83af00: /openprom
>> ff83b008:   /client-services
>> ff83c1a8: /rom@ff80
>> ff83c330:   /boot-rom@fff0
>> ff83c4a8:   /macos
>> ff83c528: /options
>> ff83c5a8: /aliases
>> ff83cec8: /packages
>> ff83cf30:   /deblocker
>> ff83d798:   /disk-label
>> ff83e198:   /obp-tftp
>> ff8439f0:   /mac-parts
>> ff844850:   /mac-files
>> ff847540:   /hfs-plus-files
>> ff84c1c8:   /fat-files
>> ff84def8:   /iso-9660-files
>> ff84eb00:   /bootinfo-loader
>> ff8507a0:   /xcoff-loader
>> ff8511b8:   /pe-loader
>> ff851b90:   /elf-loader
>> ff8531c0:   /usb-hid-class
>> ff8554d8:   /usb-ms-class
>> ff8576a8:   /sbp2-disk
>> ff858ac0:   /ata-disk
>> ff859cd8:   /atapi-disk
>> ff85b348:   /bootpath-search
>> ff861b68:   /terminal-emulator
>> ff861c00: /psuedo-hid
>> ff861c88:   /keyboard
>> ff862308:   /mouse
>> ff862820: /multiboot
>> ff86e7f0: /diagnostics
>> ff86e858: /tools-node
>> ff8704b8: /rtas
>> ff8706b8: /nvram@fff04000
>> ff871180: /uni-n@f800
>> ff8713c8:   /i2c@f8001000
>> ff871b10: /cereal
>> ff8721c0: /pci@f000
>> ff898cd0:   /uni-north-agp@b
>> ff898f40:   /ATY,Rage128Ps@10
>> ff873268: /pci@f200
>> ff8742d8:   /pci-bridge@d
>> ff876368: /mac-io@7
>> ff8773a0:   /interrupt-controller@4
>> ff877548:   /gpio@50
>> ff877630: /extint-gpio1
>> ff8777c8: /programmer-switch
>> ff877900:   /escc-legacy@12000
>> ff877af8: /ch-a@12004
>> ff877c78: /ch-b@12000
>> ff877df8:   /escc@13000
>> ff878000: /ch-a@13020
>> ff8789a8: /ch-b@13000
>> ff8792c0:   /davbus@14000
>> ff879540: /sound
>> ff879c40:   /timer@15000
>> ff879da8:   /via-pmu@16000
>> ff87ccf0: /rtc
>> ff87d3e0: /power-mgt
>> ff8bf378:   /usb-power-mgt
>> ff87d648:   /i2c@18000
>> ff87ded8: /cereal
>> ff87e5a0:   /ata-4@1f000
>> ff880318: /disk
>> ff8809e8:   /ata-3@2
>> ff882760: /disk
>> ff882da8:   /ata-3@21000
>> ff884b20: /disk
>> ff8864c8: /ethernet@4
>> ff888690: /usb@8
>> ff88dd50: /usb@9
>> ff8be3f0:   /hub@1
>> ff8be580: /keyboard@1
>> ff893410: /firewire@a
>> ff8752e8: /pci@f400
>> ff8bb128:   /ethernet@f
> 
> I've done quite a bit of work on Cormac's tree (primarily to fix CUDA
> issues that broke OS X among other things) and posted it to the
> qemu-devel list at
> https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05556.html.
> 
> The patchset posted works well for me here, and I suspect will fix the
> issues that you've been seeing. Note that you'll also need the separate
> OpenBIOS binary mentioned in the link above if you want to try booting
> OS 9 since one of the OpenBIOS patches hasn't been applied to trunk
> since it regresses other images.

It looks like you are saying you wish to keep the CUDA device. Mac OS 9 is most
likely hard coded to expect via-pmu instead of via-cuda on the mac99 target.
Moving on to via-pmu might make QEMU more compatible with Mac OS 9.
I will still try your patches. Do you have a repo that I could just clone? It 
is a
lot less error prone than patches. 

[Qemu-devel] CUDA has problems with Mac OS 10.4

[Programmingkid]

I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 
10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use 
the mac99 target. Here is the error message: 

panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR

This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom 
~/tiger.iso  -prom-env boot-args=-v -usb -M mac99

I think there is still something wrong with CUDA. But we might not have to 
"fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is 
what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't 
have a CUDA chip. This chip is used for ADB communications. Using it only on 
the BeigeG3 target makes sense. 

My sources for the PowerMac3,1 system is this link: 
http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp.html

and this device tree:

PowerMac G4 device tree

ff839ab8: /cpus
ff839ce8:   /PowerPC,G4@0
ff83a060: /l2-cache
ff83ab58: /chosen
ff83ace8: /memory@0
ff83af00: /openprom
ff83b008:   /client-services
ff83c1a8: /rom@ff80
ff83c330:   /boot-rom@fff0
ff83c4a8:   /macos
ff83c528: /options
ff83c5a8: /aliases
ff83cec8: /packages
ff83cf30:   /deblocker
ff83d798:   /disk-label
ff83e198:   /obp-tftp
ff8439f0:   /mac-parts
ff844850:   /mac-files
ff847540:   /hfs-plus-files
ff84c1c8:   /fat-files
ff84def8:   /iso-9660-files
ff84eb00:   /bootinfo-loader
ff8507a0:   /xcoff-loader
ff8511b8:   /pe-loader
ff851b90:   /elf-loader
ff8531c0:   /usb-hid-class
ff8554d8:   /usb-ms-class
ff8576a8:   /sbp2-disk
ff858ac0:   /ata-disk
ff859cd8:   /atapi-disk
ff85b348:   /bootpath-search
ff861b68:   /terminal-emulator
ff861c00: /psuedo-hid
ff861c88:   /keyboard
ff862308:   /mouse
ff862820: /multiboot
ff86e7f0: /diagnostics
ff86e858: /tools-node
ff8704b8: /rtas
ff8706b8: /nvram@fff04000
ff871180: /uni-n@f800
ff8713c8:   /i2c@f8001000
ff871b10: /cereal
ff8721c0: /pci@f000
ff898cd0:   /uni-north-agp@b
ff898f40:   /ATY,Rage128Ps@10
ff873268: /pci@f200
ff8742d8:   /pci-bridge@d
ff876368: /mac-io@7
ff8773a0:   /interrupt-controller@4
ff877548:   /gpio@50
ff877630: /extint-gpio1
ff8777c8: /programmer-switch
ff877900:   /escc-legacy@12000
ff877af8: /ch-a@12004
ff877c78: /ch-b@12000
ff877df8:   /escc@13000
ff878000: /ch-a@13020
ff8789a8: /ch-b@13000
ff8792c0:   /davbus@14000
ff879540: /sound
ff879c40:   /timer@15000
ff879da8:   /via-pmu@16000
ff87ccf0: /rtc
ff87d3e0: /power-mgt
ff8bf378:   /usb-power-mgt
ff87d648:   /i2c@18000
ff87ded8: /cereal
ff87e5a0:   /ata-4@1f000
ff880318: /disk
ff8809e8:   /ata-3@2
ff882760: /disk
ff882da8:   /ata-3@21000
ff884b20: /disk
ff8864c8: /ethernet@4
ff888690: /usb@8
ff88dd50: /usb@9
ff8be3f0:   /hub@1
ff8be580: /keyboard@1
ff893410: /firewire@a
ff8752e8: /pci@f400
ff8bb128:   /ethernet@f

Re: [Qemu-devel] [PATCH] hw/usb/dev-audio.c: make USB audio card sound perfect

[Programmingkid]

On Oct 29, 2015, at 11:08 AM, Stefan Hajnoczi wrote:

> On Wed, Oct 28, 2015 at 09:59:32AM -0400, Programmingkid wrote:
>> 
>> On Oct 28, 2015, at 6:58 AM, Stefan Hajnoczi wrote:
>> 
>>> On Mon, Oct 26, 2015 at 01:24:00PM +0100, Gerd Hoffmann wrote:
>>>>> So this change would make real-time audio feel laggy.
>>>> 
>>>> That is secondary if the sound quality is bad due to constant overruns
>>>> and underruns ...
>>> 
>>> This is like sweeping network performance problems under the rug by
>>> increasing queue size.
>>> 
>>> Before bumping the buffer size and breaking real-time applications (i.e.
>>> 128-512 samples per buffer), there should be a little performance
>>> investigation to understand the root cause.
>>> 
>>> Why are overruns/underruns occurring?
>>> 
>>> Is the problem the host sound API, QEMU's audio/mixing infrastructure,
>>> or guest responsiveness?
>> 
>> I think a better question is who is going to spend the time and energy 
>> trying to answer these questions?
> 
> To push patches like this is arrogant because your patch makes a
> trade-off: smooth playback on *your* system vs worse latency for
> *everyone*.

I'm sorry you are taking this so personally. I would never have submitted this
patch if it causes a lot of problems to others. 

> You don't want to spend time understanding why playback is choppy on
> your system.  That's fine.

I have been working on a sound output related problem for years.


> What bothers me is that you have no qualms about making latency on
> everyone's system worse.

How do you know it makes sound on other people's systems worse? If you have
actually done any testing, I would like to see the results. 

Here is a format I suggest you could use:

Host operating system:
Guest operating system:
emulated machine:
Tests conducted: video playback, game sound playback, ...


> If you don't have time, that's fine.  Just send an email to report the
> symptom and in the meantime use the qdev property to increase the buffer
> size for yourself:
> 
>  -device usb-audio,buffer=6144

The thing is I am certain is this patch makes sound play better. Before this 
patch the sound
played back from the usb audio device was very poor. With this patch it sounds
great. I have played video files in QEMU and if the latency was really high, 
then
I would have noticed the audio not being in sync with the video. 

You have shown calculations, but you haven't given any real world examples
of why this patch is bad. 

Re: [Qemu-devel] [PATCH] hw/usb/dev-audio.c: make USB audio card sound perfect

[Programmingkid]

On Oct 28, 2015, at 6:58 AM, Stefan Hajnoczi wrote:

> On Mon, Oct 26, 2015 at 01:24:00PM +0100, Gerd Hoffmann wrote:
>>> So this change would make real-time audio feel laggy.
>> 
>> That is secondary if the sound quality is bad due to constant overruns
>> and underruns ...
> 
> This is like sweeping network performance problems under the rug by
> increasing queue size.
> 
> Before bumping the buffer size and breaking real-time applications (i.e.
> 128-512 samples per buffer), there should be a little performance
> investigation to understand the root cause.
> 
> Why are overruns/underruns occurring?
> 
> Is the problem the host sound API, QEMU's audio/mixing infrastructure,
> or guest responsiveness?

I think a better question is who is going to spend the time and energy 
trying to answer these questions?

How about this, we apply the patch for now, and if someone does figures
out a better way of solving this problem, we use the better way in the future.

Re: [Qemu-devel] [PATCH] hw/usb/dev-audio.c: make USB audio card sound perfect

[Programmingkid]

On Oct 26, 2015, at 8:24 AM, Gerd Hoffmann wrote:

>  Hi,
> 
>> So this change would make real-time audio feel laggy.
> 
> That is secondary if the sound quality is bad due to constant overruns
> and underruns ...
> 
>> Unless Gerd has a
>> strong feeling that it's an improvement for QEMU, I wouldn't merge this
>> change.
> 
> The change is merged.
> 
> cheers,
>  Gerd

Thank you.

Re: [Qemu-devel] [PATCH] hw/usb/dev-audio.c: make USB audio card sound perfect

[Programmingkid]

On Oct 26, 2015, at 7:00 AM, Stefan Hajnoczi wrote:

> On Fri, Oct 16, 2015 at 09:54:12AM -0400, Programmingkid wrote:
>> 
>> On Oct 16, 2015, at 8:15 AM, Stefan Hajnoczi wrote:
>> 
>>> On Tue, Sep 22, 2015 at 07:32:01PM -0400, Programmingkid wrote:
>>>> The USB audio card would not play audio well because its buffer was too 
>>>> small. 
>>>> Increasing it made it play perfectly. All the crackling and dropouts are 
>>>> gone.  
>>>> 
>>>> Signed-off-by: John Arbuckle 
>>>> 
>>>> ---
>>>> This patch was tested on qemu-system-ppc running Linux and qemu-system-i386
>>>> running Windows XP. Windows XP sound output thru the USB audio card sounded
>>>> perfect. Linux did improve in sound quality, but it still wasn't perfect. I
>>>> think there are problems with the hcd-ohci.c file. The Mac OS 10.2 guest 
>>>> in 
>>>> qemu-system-ppc did not play sound due to USB issues unrelated to this 
>>>> patch. 
>>>> 
>>>> hw/usb/dev-audio.c |3 ++-
>>>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>>> 
>>>> diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c
>>>> index f092bb8..e4e4989 100644
>>>> --- a/hw/usb/dev-audio.c
>>>> +++ b/hw/usb/dev-audio.c
>>>> @@ -88,6 +88,7 @@ static const USBDescStrings usb_audio_stringtable = {
>>>> #define USBAUDIO_PACKET_SIZE 192
>>>> #define USBAUDIO_SAMPLE_RATE 48000
>>>> #define USBAUDIO_PACKET_INTERVAL 1
>>>> +#define BUFFER_MULTIPLIER32
>>>> 
>>>> static const USBDescIface desc_iface[] = {
>>>>{
>>>> @@ -664,7 +665,7 @@ static const VMStateDescription vmstate_usb_audio = {
>>>> static Property usb_audio_properties[] = {
>>>>DEFINE_PROP_UINT32("debug", USBAudioState, debug, 0),
>>>>DEFINE_PROP_UINT32("buffer", USBAudioState, buffer,
>>>> -   8 * USBAUDIO_PACKET_SIZE),
>>>> +   BUFFER_MULTIPLIER * USBAUDIO_PACKET_SIZE),
>>> 
>>> I'm not familiar with the code but I guess this also increases audio
>>> latency by a factor of 4 (8 -> 32).
>> 
>> Didn't hear any problems. When I tried it out. 
> 
> 8 buffers * 192 bytes / 3 byte (24-bit) mono samples = 512 samples
> 32 buffers * 192 bytes / 3 byte (24-bit) mono samples = 2048 samples
> 
> At 48 kHz sample rate that is 10.6 milliseconds vs 42.6 milliseconds
> latency.
> 
> I have never tried real-time audio processing under QEMU but when I use
> Linux for guitar effects it becomes noticable when latency is above
> around 12 milliseconds.  ~5 milliseconds latency with USB audio is
> achievable on bare metal.
> 
> So this change would make real-time audio feel laggy.  Unless Gerd has a
> strong feeling that it's an improvement for QEMU, I wouldn't merge this
> change.

Have you done any testing using this patch yet? 

I have played several MP3 files and a video file. The audio plays very well.
For the video file the audio was in-sync with the audio. I played a pinball
game and the audio did match what was going on with the action of the
game. With a powerful enough computer someone could play Guitar Hero
in QEMU and not have any problems. 

Re: [Qemu-devel] [PATCH] hw/usb/dev-audio.c: make USB audio card sound perfect

[Programmingkid]

On Oct 16, 2015, at 10:00 AM, Peter Maydell wrote:

> On 16 October 2015 at 14:54, Programmingkid  wrote:
>> 
>> On Oct 16, 2015, at 8:15 AM, Stefan Hajnoczi wrote:
>>> Gerd might have an opinion on whether that is okay or not.
>> 
>> I doubt it. I don't even think he is with QEMU anymore. He doesn't
>> even answer simple emails. He probably stopped working on
>> QEMU. I do think it is time to add another USB maintainer.
> 
> A quick check shows that Gerd has been replying to emails on list
> this week; he hasn't gone anywhere...

When I do send him emails, I use this address: kra...@redhat.com. Is
this the right address? Found it in the maintainers file.

I sent him several USB based patches and he never responded. Am I
doing something wrong or does he just not care anymore?

Re: [Qemu-devel] Determining if USB is available

[Programmingkid]

On Oct 16, 2015, at 8:48 AM, Peter Maydell wrote:

> On 16 October 2015 at 13:07, Stefan Hajnoczi  wrote:
>> On Thu, Sep 17, 2015 at 09:45:44PM -0400, Programmingkid wrote:
>>> Would you know of a function that could indicate if USB is available on the 
>>> current emulator?
>> 
>> vl.c:usb_enabled()?
> 
> Haven't checked, but a quick look at the code suggests that may
> not give the correct answer if the USB is provided by an emulated
> PCI USB card?

It is ok. I have solved this problem by I think checking for a USB bus. 

Re: [Qemu-devel] Determining if USB is available

[Programmingkid]

On Oct 16, 2015, at 8:07 AM, Stefan Hajnoczi wrote:

> On Thu, Sep 17, 2015 at 09:45:44PM -0400, Programmingkid wrote:
>> Would you know of a function that could indicate if USB is available on the 
>> current emulator?
> 
> vl.c:usb_enabled()?

Thank you.

Re: [Qemu-devel] [PATCH] hw/usb/dev-audio.c: make USB audio card sound perfect

[Programmingkid]

On Oct 16, 2015, at 8:15 AM, Stefan Hajnoczi wrote:

> On Tue, Sep 22, 2015 at 07:32:01PM -0400, Programmingkid wrote:
>> The USB audio card would not play audio well because its buffer was too 
>> small. 
>> Increasing it made it play perfectly. All the crackling and dropouts are 
>> gone.  
>> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> This patch was tested on qemu-system-ppc running Linux and qemu-system-i386
>> running Windows XP. Windows XP sound output thru the USB audio card sounded
>> perfect. Linux did improve in sound quality, but it still wasn't perfect. I
>> think there are problems with the hcd-ohci.c file. The Mac OS 10.2 guest in 
>> qemu-system-ppc did not play sound due to USB issues unrelated to this 
>> patch. 
>> 
>> hw/usb/dev-audio.c |3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>> 
>> diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c
>> index f092bb8..e4e4989 100644
>> --- a/hw/usb/dev-audio.c
>> +++ b/hw/usb/dev-audio.c
>> @@ -88,6 +88,7 @@ static const USBDescStrings usb_audio_stringtable = {
>> #define USBAUDIO_PACKET_SIZE 192
>> #define USBAUDIO_SAMPLE_RATE 48000
>> #define USBAUDIO_PACKET_INTERVAL 1
>> +#define BUFFER_MULTIPLIER32
>> 
>> static const USBDescIface desc_iface[] = {
>> {
>> @@ -664,7 +665,7 @@ static const VMStateDescription vmstate_usb_audio = {
>> static Property usb_audio_properties[] = {
>> DEFINE_PROP_UINT32("debug", USBAudioState, debug, 0),
>> DEFINE_PROP_UINT32("buffer", USBAudioState, buffer,
>> -   8 * USBAUDIO_PACKET_SIZE),
>> +   BUFFER_MULTIPLIER * USBAUDIO_PACKET_SIZE),
> 
> I'm not familiar with the code but I guess this also increases audio
> latency by a factor of 4 (8 -> 32).

Didn't hear any problems. When I tried it out. 

> Gerd might have an opinion on whether that is okay or not.

I doubt it. I don't even think he is with QEMU anymore. He doesn't
even answer simple emails. He probably stopped working on
QEMU. I do think it is time to add another USB maintainer.

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Add real CDROM menu item

[Programmingkid]

On Oct 13, 2015, at 4:44 PM, Peter Maydell wrote:

> On 26 September 2015 at 04:01, Programmingkid  
> wrote:
>> Add a menu item to the Machine menu called "Use Real CDROM". It gives the 
>> user
>> the ability to use a real CDROM disc with QEMU by simply selecting a menu 
>> item.
>> 
>> Signed-off-by: John Arbuckle 
> 
> This feature is not present in any of our other UI frontends,
> and the implementation makes assumptions about the names of
> block devices in the models (ie that if it has "cd" in the name
> anywhere it's a CD). I also don't have a mac with a CD drive
> so I have no way of testing it.
> 
> I'm afraid that I think that this comes under the heading of
> "features that should be in the VM management layer, not QEMU
> itself", so I would prefer not to take it into QEMU.

Mac OS X users don't have any VM management layer. That is pretty much
a Linux-only feature. What we do have is the cocoa interface. 

Re: [Qemu-devel] [PATCH v3 1/4] util - add automated ID generation utility

[Programmingkid]

On Oct 13, 2015, at 11:26 AM, Markus Armbruster wrote:

> Jeff Cody  writes:
> 
>> On Tue, Oct 13, 2015 at 09:37:29AM +0200, Markus Armbruster wrote:
>>> Jeff Cody  writes:
>>> 
 Multiple sub-systems in QEMU may find it useful to generate IDs
 for objects that a user may reference via QMP or HMP.  This patch
 presents a standardized way to do it, so that automatic ID generation
 follows the same rules.
 
 This patch enforces the following rules when generating an ID:
 
 1.) Guarantee no collisions with a user-specified ID
 2.) Identify the sub-system the ID belongs to
 3.) Guarantee of uniqueness
 4.) Spoiling predictability, to avoid creating an assumption
of object ordering and parsing (i.e., we don't want users to think
they can guess the next ID based on prior behavior).
 
 The scheme for this is as follows (no spaces):
 
# subsys D RR
 Reserved char --||   | |
 Subsystem String |   | |
 Unique number (64-bit) --| |
 Two-digit random number ---|
 
 For example, a generated node-name for the block sub-system may look
 like this:
 
#block076
 
 The caller of id_generate() is responsible for freeing the generated
 node name string with g_free().
 
 Reviewed-by: John Snow 
 Reviewed-by: Eric Blake 
 Reviewed-by: Alberto Garcia 
 Signed-off-by: Jeff Cody 
 ---
 include/qemu-common.h |  8 
 util/id.c | 37 +
 2 files changed, 45 insertions(+)
 
 diff --git a/include/qemu-common.h b/include/qemu-common.h
 index 0bd212b..2f74540 100644
 --- a/include/qemu-common.h
 +++ b/include/qemu-common.h
 @@ -246,6 +246,14 @@ int64_t qemu_strtosz_suffix_unit(const char *nptr, 
 char **end,
 #define STR_OR_NULL(str) ((str) ? (str) : "null")
 
 /* id.c */
 +
 +typedef enum IdSubSystems {
 +ID_QDEV,
>>> 
>>> ID_QDEV is not used in this series.  Do you intend to use it in a
>>> followup-series?  Can we reasonably expect that series will be accepted?
>>> 
>> 
>> John Arbuckle has a patch on list that uses it.  I haven't reviewed
>> it, however - but I guess it depends ultimately on whether qdev will
>> allow autogeneration for its IDs or not.
> 
> Then that patch should add ID_QDEV.
> 
>>> You could sidestep these questions by making id_generate() take a string
>>> argument ;)
>>> 
>> 
>> I'd rather avoid having each system specifying a string inline in
>> their code.  It is cleaner to have the strings defined in a central
>> location, I think (not to mention, easier to reference).

I can see the benefit of using a string. The id_generate() function
could use va_args like printf() uses to allow almost any kind of 
string argument. An empty string argument could mean to default to
ID_MAX. But I also think using an enumeration is good enough, so 
either way is good.

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Oct 2, 2015, at 12:21 PM, Eric Blake wrote:

> On 10/02/2015 08:37 AM, Programmingkid wrote:
>>> Even if it were a fancier GUI, I don't think it would really go very far to
>>> providing users a solution which is on a par with VirtualBox or VMWare 
>>> Desktop
>>> which are the benchmarks, as the GUI will forever be limited to only dealing
>>> with a single VM at a time. As soon as you want to deal with more than 1 VM
>>> at a time, a GUI built-in to QEMU is a non-starter as you need to manage 
>>> many
>>> QEMUs. So encouraging new users to use a built-in QEMU GUI is sending them
>>> down a dead-end - we should be ensuring they can find the viable long term
>>> UI straight away. This means directing them to things like GNOME Boxes or
>>> virt-manager or one of the other UIs that exist.
>> 
>> Sorry to say but this belief you have it exactly what is keeping
>> the GUI in QEMU from being great. Can only deal with one VM at a time?
> 
> A good gui will have a single process dealing with multiple guests at a
> single time.

Going to have to agree to disagree on this point.

> 
> When you are reading email, do you want to fire up two separate email
> processes per mail?  Or do you want to fire up a single email reader,
> that can then browse multiple mails, and maybe even open multiple
> windows to compare mails side by side?
> When you open your browser, do you want to have two browser processes
> for separate URLs open at the same time?  Or do you want a single
> browser with multiple tabs?

This may be fine for emails and web pages, but we are talking about
emulators here. I'm not against this idea, but improving QEMU's GUI and
implementing this megaGUI can happen at the same time. 

> We already KNOW that qemu only manages one guest at a time.  But I argue
> that any GOOD gui for managing guests can manage multiple guests in a
> single gui process. So qemu is NOT the place to be working on a GOOD
> gui.  It only needs enough of a gui to make development easier, NOT to
> make end user life easier.

Definitely going to have to agree to disagree on this point.

> 
> We WANT to point end users to a better application, _built on top of
> qemu_.  Whether that be GNOME boxes, virt-manager, or some new tool, I
> don't care.  But we do NOT want qemu to become that tool.

Everybody can win in this situation. The Anti-GUI people can win by using 
--disable-gtk/--disable-cocoa, and the Pro-GUI people can win by using
their respective GUI's. 

> Instead of wasting our time beating a dead horse, you'd get further if
> you started porting one of the existing VM guis that can already manage
> qemu to run well on OS X.

That is much easier said than done. What you want could take years to
accomplish. Adding a few features to the GUI doesn't sound that bad. It
also doesn't hurt someone who doesn't use the GUI, so why have a problem
with it?

> 
>> The GUI in QEMU can become great. We just have to let it do so. 
> 
> No.  Please don't.  I do not want the qemu gui to be a selling point of
> qemu.

Selling point? Are you afraid a really good GUI for QEMU might put
Libvirt out of business? Isn't the general trend in technology for things
to become better? Trying to hold back the GUI is anti-technology 
thinking. We need pro-technology thinkers to advance our way of
life. I am sure that technology has put people out of business. If you 
want to cling to the pony express way of life, good luck. I think you 
and everyone else would be much better suited to moving forward
and adapting to change. 

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Oct 2, 2015, at 10:28 AM, Daniel P. Berrange wrote:

> On Fri, Oct 02, 2015 at 02:33:22PM +0100, Dr. David Alan Gilbert wrote:
>> * Daniel P. Berrange (berra...@redhat.com) wrote:
>>> On Wed, Sep 30, 2015 at 09:48:25AM +0200, Markus Armbruster wrote:
 "Dr. David Alan Gilbert"  writes:
>> 
>>> I don't find the lack of expertise argument very compelling in general, as
>>> that's just a self-fullfilling prophecy really. I do agree though, that
>>> building a fully featured mgmt UI in QEMU is a distraction from more
>>> important work in QEMU's core mission.
>>> 
>> 
>>> I also think this last point about having security separation between QEMU
>>> and the GUI layer is really a killer argument against having any kind of
>>> non-trivial GUI built-in to QEMU.
>> 
>> We already have a GUI (at least 2...)
> 
> Right, but they're very feature limited in what they do - essentially only
> used by developers for ad-hoc testing - few people are using them in the
> real world for production deployments. That's a reasonably well constrained
> scenario with no need for growth in features.
> 
>> Defining a 'core mission' is very difficult.  While it's true that many
>> of us have to mostly worry about security in big farms of servers, some 
>> people
>> just want to run another OS on their desktop, and while they want it secure
>> they also want it to have fast graphics.   I'm not sure we currently have
>> a story for how to do separation from QEMU and fast graphics.
> 
> IIUC, the intention with virgl is to allowing QEMU to pass an FD back to the
> SPICE/VNC client which they can use to access the render context to avoid
> expensive copying.
> 
>>> I get the opinion that most maintainers consider that the QEMU GUI is just
>>> there to provide the bare minimum infrastructure to interact with the guest
>>> without relying on external services like SPICE/VNC. IOW it is not there as
>>> a building block for creating a full management UI around QEMU. I think it
>>> would be helpful to explicitly spell this out in docs somewhere, so people
>>> looking at QEMU cna easily identify that we're not looking for patches to
>>> add mgmt features in the QEMU GUI and they should invest their time in GUI
>>> efforts built on top of QEMU.
>> 
>> But how bare do you want it to be?  Many users get put off by the sparsity
>> of the GUI and just use something else instead.
> 
> Even if it were a fancier GUI, I don't think it would really go very far to
> providing users a solution which is on a par with VirtualBox or VMWare Desktop
> which are the benchmarks, as the GUI will forever be limited to only dealing
> with a single VM at a time. As soon as you want to deal with more than 1 VM
> at a time, a GUI built-in to QEMU is a non-starter as you need to manage many
> QEMUs. So encouraging new users to use a built-in QEMU GUI is sending them
> down a dead-end - we should be ensuring they can find the viable long term
> UI straight away. This means directing them to things like GNOME Boxes or
> virt-manager or one of the other UIs that exist.

Sorry to say but this belief you have it exactly what is keeping
the GUI in QEMU from being great. Can only deal with one VM at a time?
I can have both qemu-system-ppc and qemu-system-i386 running at the
same time and they both have the same GUI. They are two separate
programs so no problems with them both running. 

Conditional codes can make the GUI more self-customizing to the various
machine emulators. Features like USB can be detected at runtime and
handled accordingly. 

The GUI in QEMU can become great. We just have to let it do so. 

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Oct 2, 2015, at 8:33 AM, Daniel P. Berrange wrote:

> On Wed, Sep 30, 2015 at 11:53:50AM +0100, Peter Maydell wrote:
>> On 30 September 2015 at 09:14, Dr. David Alan Gilbert
>>  wrote:
>>> * Markus Armbruster (arm...@redhat.com) wrote:
 In my opinion, QEMU should leave them to separate GUI shells, because
 doing everything in QEMU distracts from our core mission and we don't
 have GUI expertise[*].  One more point: building in the GUI is
 problematic when you don't trust the guest, because then you really want
 to run QEMU with least privileges.
>>> 
>>> Given that we have a built in GUI then I can see people wanting to expand
>>> it.
>> 
>> Right, but where do you draw the line? We clearly don't have the
>> active maintainer and review capacity to do anything serious with
>> "ui/" (MAINTAINERS lists everything except SPICE as Odd Fixes).
>> 
>> This is why I tend to agree with Markus' opinion here: we should
>> provide enough graphical UI to make raw QEMU minimally usable,
>> and leave further user-friendliness to other projects which have
>> more direct interest in that.
>> 
>> If we had more regular contributors who were actively interested
>> in improving our UI layer my opinion might be different.
> 
> Even if we had more contributors interested in that, I still think
> that we should not do it, because building a UI into QEMU is a
> fundamentally bad design / architecture.

Why is it a bad design? I know that the Linux custom is to make a command
then possibly make a GUI that wraps around the command, but QEMU
doesn't just run on Linux. It runs on Mac OS X, Windows, Solaris,
FreeBSD, and maybe some more OS's. Applying the design
decisions of one OS to all OS's isn't necessarily a good idea

> QEMU is a security
> sensitive component and we want to know the boundaries of what
> a guest exploit can achieve - including a GUI massively expands
> the attack surface making it more or less impossible to confine
> any QEMU exploit, even with tools like SELinux/AppArmour, because
> you have to allow use of the desktop protocol at which point you
> can just talk to a separate app to perform the exploit.

The answer is simple in this situation. Just don't run a GUI with QEMU.
There is --disable-sdl, --disable-gtk, and --disable-cocoa. No more
GUI - security problems solved. 

Re: [Qemu-devel] About the sd card reader

[Programmingkid]

On Oct 1, 2015, at 9:23 AM, Stefan Hajnoczi wrote:

> On Sat, Sep 26, 2015 at 10:24:31AM -0400, Programmingkid wrote:
>> I was looking at the commit history for sd.c and noticed your patch. Would 
>> you know how to make the SD card reader work for a guest like Windows, 
>> Linux, or Mac OS X? I'm trying to use this device on qemu-system-ppc and 
>> qemu-system-i386. Any help would be great.
> 
> sd.c is the core SD card emulation code.  It's not a complete device
> itself, you need a host controller interface like sdhci.c.
> 
> The sdhci-pci device might work, if you can tell a Windows/Mac/etc SDHCI
> PCI driver to accept the Red Hat 1fa4:0007 PCI ID.
> 
> Stefan

Would this device work if I installed Red Hat Linux in qemu-system-i386? 

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 30, 2015, at 6:53 AM, Peter Maydell wrote:

> On 30 September 2015 at 09:14, Dr. David Alan Gilbert
>  wrote:
>> * Markus Armbruster (arm...@redhat.com) wrote:
>>> In my opinion, QEMU should leave them to separate GUI shells, because
>>> doing everything in QEMU distracts from our core mission and we don't
>>> have GUI expertise[*].  One more point: building in the GUI is
>>> problematic when you don't trust the guest, because then you really want
>>> to run QEMU with least privileges.
>> 
>> Given that we have a built in GUI then I can see people wanting to expand
>> it.
> 
> Right, but where do you draw the line? We clearly don't have the
> active maintainer and review capacity to do anything serious with
> "ui/" (MAINTAINERS lists everything except SPICE as Odd Fixes).

This could be changed. 

> This is why I tend to agree with Markus' opinion here: we should
> provide enough graphical UI to make raw QEMU minimally usable,
> and leave further user-friendliness to other projects which have
> more direct interest in that.
> 
> If we had more regular contributors who were actively interested
> in improving our UI layer my opinion might be different.

It is really hard for more contributors to come when the maintainers
keep discouraging them. 

Re: [Qemu-devel] [PATCH] ui/cocoa.m: run custom script menu item

[Programmingkid]

On Sep 29, 2015, at 2:00 PM, Peter Maydell wrote:

> On 29 September 2015 at 18:53, Programmingkid  
> wrote:
>> 
>> On Sep 29, 2015, at 1:18 PM, Peter Maydell wrote:
>> 
>>> On 29 September 2015 at 18:03, Programmingkid  
>>> wrote:
>>>> Allow the user the ability to run a custom script file.
>>>> This patch adds a menu item called "Run Custom Script".
>>>> When the user selects it, a open-file dialog has the
>>>> user select a text file with the custom scripts to run.
>>>> This allows for virtually unlimited expandability. All
>>>> monitor commands should work with this feature.
> 
>>> Not a feature I want in the cocoa UI, please.
>> 
>> It can be consider it a poor man's Virt-manager. It is very small
>> and light. It can help a lot of people out. I really believe in this
>> feature. It can encompass a lot of the GUI features in most
>> front-ends. Think about it, the user might never have to enter
>> long file paths again with this feature. It makes life so much
>> easier for QEMU users.
> 
> I simply do not have the time or expertise to review
> these patches for significant new OSX UI layer features.
> (OSX host support is something I do as a sideline to the work I'm
> paid to do on QEMU, and so my time for it is decidedly limited.)
> 
> This leaves you with three choices:
> * find another core developer who will review these for you
> * implement them for some other QEMU UI layer on a platform
>   which has more people who care about it and thus gets more
>   review (ie Linux+GTK or SDL), and then do the OSX UI updates
>   second as a "bring in line with GTK" change
> * implement these features in a separate virt-manager for OSX
> 
> I can continue to review bugfix patches and similar.
> 
> thanks
> -- PMM

Adding more maintainers sounds like a great idea.

[Qemu-devel] [PATCH] ui/cocoa.m: run custom script menu item

[Programmingkid]

Allow the user the ability to run a custom script file.
This patch adds a menu item called "Run Custom Script".
When the user selects it, a open-file dialog has the
user select a text file with the custom scripts to run.
This allows for virtually unlimited expandability. All
monitor commands should work with this feature.

Signed-off-by: John Arbuckle 

---
To test this patch, save this text "sendkey ctrl-alt-delete"
in a text file. Then run a Windows guest to try out this
feature. That is only a sample of what this patch could do.
Mounting image files, debugging, and saving states are just
a few of the things this patch can help the user to accomplish.

 ui/cocoa.m |   75 
 1 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..15a28f0 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -263,6 +263,44 @@ static void handleAnyDeviceErrors(Error * err)
 }
 }
 
+/* Sends a command to the monitor console */
+static void sendMonitorCommand(const char *command_string)
+{
+int index;
+char *console_name;
+static QemuConsole *monitor = NULL;
+
+/* If the monitor console hasn't been found yet */
+if(!monitor) {
+index = 0;
+/* Find the monitor console */
+while (qemu_console_lookup_by_index(index) != NULL) {
+console_name = qemu_console_get_label(
+   
qemu_console_lookup_by_index(index));
+if(strstr(console_name, "monitor")) {
+monitor = qemu_console_lookup_by_index(index);
+break;
+}
+index++;
+}
+}
+
+/* If the monitor console was not found */
+if(!monitor) {
+NSBeep();
+QEMU_Alert(@"Sorry but the monitor isn't available.");
+return;
+}
+
+/* send each letter in the commandString to the monitor */
+for (index = 0; index < strlen(command_string); index++) {
+kbd_put_keysym_console(monitor, command_string[index]);
+}
+
+/* simulate the user pushing the return key */
+kbd_put_keysym_console(monitor, '\n');
+}
+
 /*
  --
 QemuCocoaView
@@ -829,6 +867,7 @@ QemuCocoaView *cocoaView;
 - (void)powerDownQEMU:(id)sender;
 - (void)ejectDeviceMedia:(id)sender;
 - (void)changeDeviceMedia:(id)sender;
+- (void)runScript:(id)sender;
 @end
 
 @implementation QemuCocoaAppController
@@ -1125,6 +1164,31 @@ QemuCocoaView *cocoaView;
 }
 }
 
+/* Runs a user's custom script */
+- (void)runScript:(id)sender
+{
+NSOpenPanel *openPanel = [NSOpenPanel openPanel];
+[openPanel setTitle: @"Select a script file"];
+if([openPanel runModal] == NSFileHandlingPanelOKButton) {
+NSString *file_buffer, *file_path;
+NSError *err = nil;
+file_path = [[openPanel URL] path];
+file_buffer = [NSString stringWithContentsOfFile:file_path
+encoding:NSASCIIStringEncoding
+   error:&err];
+
+if(err) {
+NSString *message = [NSString stringWithFormat: @"Error: %@",
+  [err 
localizedFailureReason]];
+NSBeep();
+QEMU_Alert(message);
+return;
+}
+sendMonitorCommand([file_buffer cStringUsingEncoding:
+  NSASCIIStringEncoding]);
+}
+}
+
 @end
 
 
@@ -1184,6 +1248,17 @@ int main (int argc, const char * argv[]) {
 [[NSApp mainMenu] addItem:menuItem];
 [NSApp performSelector:@selector(setAppleMenu:) withObject:menu]; // 
Workaround (this method is private since 10.4+)
 
+// File menu
+menu = [[NSMenu alloc] initWithTitle:@"File"];
+[menu addItem: [[[NSMenuItem alloc] initWithTitle:@"Run custom script..."
+action:@selector(runScript:)
+ keyEquivalent:@""] autorelease]];
+menuItem = [[[NSMenuItem alloc] initWithTitle:@"File"
+   action:nil keyEquivalent:@""]
+   
autorelease];
+[menuItem setSubmenu:menu];
+[[NSApp mainMenu] addItem:menuItem];
+
 // Machine menu
 menu = [[NSMenu alloc] initWithTitle: @"Machine"];
 [menu setAutoenablesItems: NO];
-- 
1.7.5.4

Re: [Qemu-devel] [PATCH] ui/cocoa.m: run custom script menu item

[Programmingkid]

On Sep 29, 2015, at 1:18 PM, Peter Maydell wrote:

> On 29 September 2015 at 18:03, Programmingkid  
> wrote:
>> Allow the user the ability to run a custom script file.
>> This patch adds a menu item called "Run Custom Script".
>> When the user selects it, a open-file dialog has the
>> user select a text file with the custom scripts to run.
>> This allows for virtually unlimited expandability. All
>> monitor commands should work with this feature.
>> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> To test this patch, save this text "sendkey ctrl-alt-delete"
>> in a text file. Then run a Windows guest to try out this
>> feature. That is only a sample of what this patch could do.
>> Mounting image files, debugging, and saving states are just
>> a few of the things this patch can help the user to accomplish.
> 
> Not a feature I want in the cocoa UI, please.

It can be consider it a poor man's Virt-manager. It is very small
and light. It can help a lot of people out. I really believe in this
feature. It can encompass a lot of the GUI features in most
front-ends. Think about it, the user might never have to enter
long file paths again with this feature. It makes life so much
easier for QEMU users.

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 29, 2015, at 9:11 AM, Dr. David Alan Gilbert wrote:

> * Peter Maydell (peter.mayd...@linaro.org) wrote:
>> On 28 September 2015 at 20:43, Programmingkid  
>> wrote:
>>> 
>>> On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
>>> 
>>>> Programmingkid  writes:
>>>>>A menu item
>>>>> that displays a file open dialog is very easy to use. The user just 
>>>>> selects
>>>>> a file and QEMU loads and runs all the commands in it. This feature
>>>>> would make QEMU easier to use. It would also make QEMU easily
>>>>> expandable. Typing long commands in the monitor is difficult and
>>>>> error prone. Saving these commands in a file would make it much
>>>>> easier for the user. An example command someone could put in a
>>>>> file is sending Control-Alt-Delete to the emulator. Another command
>>>>> could be mounting an image file. This feature would make things
>>>>> much easier for the user.
>>>> 
>>>> You didn't mention you're talking about a *GUI* feature.
>>> 
>>> I'm thinking it would be easier to send in the patch rather than talk about
>>> what this feature could be.
>> 
>> I think Markus and I are trying to save you that effort by
>> pointing out that this is a VM management layer feature,
>> not a core QEMU feature.
> 
> OK, so I'm going to agree with Programmingkid here.
> I think this would be a useful feature to have in QEMU; I've
> got gratuitous hacks in some of my test scripts that work
> around it not being there.
> 
> I think there are two possible things, both of which seem fairly
> easy:
>  1) Add a -chardev from file that works in this case
> (I don't think the current chardev file works does it?)
> 
>  2) A 'source' like command.

My idea was to just send the command to the monitor as if the user typed them 
up.

Re: [Qemu-devel] [PATCH v3] ui/cocoa.m: Add Mount image file menu item

[Programmingkid]

On Sep 28, 2015, at 4:09 PM, Markus Armbruster wrote:

> Programmingkid  writes:
> 
>> On Sep 25, 2015, at 11:42 AM, Markus Armbruster wrote:
>> 
>>> Programmingkid  writes:
>>> 
>>>> On Sep 24, 2015, at 2:57 AM, Markus Armbruster wrote:
>>>> 
>>>>> Programmingkid  writes:
>>>>> 
>>>>>> On Sep 23, 2015, at 4:35 PM, Peter Maydell wrote:
>>>>>> 
>>>>>>> On 17 September 2015 at 21:17, Programmingkid
>>>>>>>  wrote:
>>>>>>>> Add "Mount Image File..." and a "Eject Image File" menu items to
>>>>>>>> cocoa interface. This patch makes sharing files between the
>>>>>>>> host and the guest user-friendly.
>>>>>>>> 
>>>>>>>> The "Mount Image File..." menu item displays a dialog box having the
>>>>>>>> user pick an image file to use in QEMU. The image file is setup as
>>>>>>>> a USB flash drive. The user can do the equivalent of removing the
>>>>>>>> flash drive by selecting the file in the "Eject Image File" submenu.
>>>>>>>> 
>>>>>>>> Signed-off-by: John Arbuckle 
>>>>>>> 
>>>>>>> I've thought a bit about this, and I really don't think this sort
>>>>>>> of feature should be part of QEMU itself. Our general design for
>>>>>>> how QEMU does this sort of thing is that an external program
>>>>>>> (virt-manager, for instance) is responsible for providing most
>>>>>>> of the UI conveniences the user wants, and QEMU's "ui" code is
>>>>>>> a fairly simple minimum-functionality affair. I agree with Markus
>>>>>>> that this separation of concerns has generally worked OK for us.
>>>>>>> 
>>>>>>> I don't think OSX should be an exception to this design model:
>>>>>>> (a) being an odd special case is never a good idea
>>>>>>> (b) as a practical matter, I'm the only person who really reviews
>>>>>>> OSX patches, and I don't have either the time nor the UI or OSX
>>>>>>> expertise to deal with maintaining what will effectively be a
>>>>>>> vm-manager grafted onto the side of QEMU
>>>>>>> 
>>>>>>> So I think your efforts would be better spent in either porting
>>>>>>> one of the Linux frontends like libvirt/virt-manager, or in
>>>>>>> writing a custom OSX specific frontend.
>>>>>> 
>>>>>> I understand that time is precious. It is one of those things
>>>>>> that we only have a finite amount of. Every user can agree
>>>>>> to that. This patch was pretty hairy looking with the QDict
>>>>>> and other unfamiliar code. With that said I'm not ready to
>>>>>> give up on this patch. It is a huge time saver for the user.
>>>>>> Without it, the user would need to spend a lot of time
>>>>>> investigating documentation. What's worse is the user
>>>>>> would have to type out full paths to files they need. This
>>>>>> would definitely be error prone and frustrating.
>>>>> 
>>>>> Nobody is challenging the idea that many users appreciate a GUI.
>>>>> 
>>>>> What we've been trying to tell you is where in this software layer cake
>>>>> the GUI should be.  In Peter's words, "our general design for how QEMU
>>>>> does this sort of thing is that an external program (virt-manager, for
>>>>> instance) is responsible for providing most of the UI conveniences".
>>>> 
>>>> That is easy for you to say. Linux already has virt-manager. Mac OS
>>>> X doesn't.
>>>> Expecting someone to just go and port another program to Mac OS X is 
>>>> unreasonable. The amount of time and energy it would take to do so
>>>> would make it hard. 
>>> 
>>> On the purely technical level, it may or may not be harder than mashing
>>> everything into QEMU.
>>> 
>>> On the getting-patches-merged level, mashing everything into QEMU is a
>>> non-starter, as Peter and I have told you multiple times.
>>> 
>>> That tips the balance somewhat.
>>> 
>>&g

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 28, 2015, at 3:44 PM, Peter Maydell wrote:

> On 28 September 2015 at 20:43, Programmingkid  
> wrote:
>> 
>> On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
>> 
>>> Programmingkid  writes:
>>>>A menu item
>>>> that displays a file open dialog is very easy to use. The user just selects
>>>> a file and QEMU loads and runs all the commands in it. This feature
>>>> would make QEMU easier to use. It would also make QEMU easily
>>>> expandable. Typing long commands in the monitor is difficult and
>>>> error prone. Saving these commands in a file would make it much
>>>> easier for the user. An example command someone could put in a
>>>> file is sending Control-Alt-Delete to the emulator. Another command
>>>> could be mounting an image file. This feature would make things
>>>> much easier for the user.
>>> 
>>> You didn't mention you're talking about a *GUI* feature.
>> 
>> I'm thinking it would be easier to send in the patch rather than talk about
>> what this feature could be.
> 
> I think Markus and I are trying to save you that effort by
> pointing out that this is a VM management layer feature,
> not a core QEMU feature.

It would be a simple patch that would be short and sweet. The possibilities 
would
be endless with what the user could use this feature for. I will not implement 
it  :(

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:

> Programmingkid  writes:
> 
>> On Sep 27, 2015, at 10:30 PM, Michael Roth wrote:
>> 
>>> Quoting Programmingkid (2015-09-27 20:49:24)
>>>> 
>>>> On Sep 27, 2015, at 2:53 PM, Peter Crosthwaite wrote:
>>>> 
>>>>> On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell
>>>>>  wrote:
>>>>>> On 27 September 2015 at 04:39, Programmingkid
>>>>>>  wrote:
>>>>>>> Would you be open to a feature that allows the user to select
>>>>>>> and run a custom file that has commands in it that would run
>>>>>>> in the monitor?
>>>>>> 
>>>>>> Sounds like a VM management layer feature.
>>>>>> 
>>>>> 
>>>>> Should -monitor file:/foo/bar do something like this?
>>>> 
>>>> If you are saying this command line argument loads monitor commands,
>>>> then it would only work when QEMU is first started. The feature I want
>>>> would work anytime during the running of QEMU. 
>>> 
>>> For that sort of flexibility I think writing commands to a socket via
>>> a script/program is simple enough that an additional interface doesn't
>>> seem worthwhile. Even our qtest unit tests use this approach. Plus you
>>> get the flexibility of a being able to branch based on the return
>>> value of commands (error-handling, stateful commands, incorporating
>>> output from a serial console, etc.). It seems like a nice feature but
>>> it's vastly inferior to what's possible with an external driver.
>> 
>> How many people know how to communicate with QEMU via a socket?
>> How do you even do it? It doesn't sound very easy to do.
> 
> It's easy, as QEMU command line goes:
> 
>-qmp unix:test-hmp,server,nowait
> 
> This is syntactic sugar for something like
> 
>-chardev socket,id=compat_monitor1,path=sock-qmp,server=on,wait=off
>-mon mode=control,chardev=compat_monitor1
> 
> The long form is more flexible.  If you use it, don't use
> id=compat_monitor1, obviously.
> 
> Easier on the eyes as configuration file for -readconfig:
> 
>[chardev "qmp"]
>  backend = "socket"
>  path = "sock-qmp"
>  server = "on"
>  wait = "off"
> 
>[mon "qmp"]
>  mode = "control"
>  chardev = "qmp"
> 
>> A menu item
>> that displays a file open dialog is very easy to use. The user just selects
>> a file and QEMU loads and runs all the commands in it. This feature
>> would make QEMU easier to use. It would also make QEMU easily
>> expandable. Typing long commands in the monitor is difficult and
>> error prone. Saving these commands in a file would make it much
>> easier for the user. An example command someone could put in a
>> file is sending Control-Alt-Delete to the emulator. Another command
>> could be mounting an image file. This feature would make things
>> much easier for the user.
> 
> You didn't mention you're talking about a *GUI* feature.

I'm thinking it would be easier to send in the patch rather than talk about 
what this feature could be. 

[Qemu-devel] ping: [PATCH v5] raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

Is there a reason why this patch hasn't been reviewed yet?

http://patchwork.ozlabs.org/patch/500498/

> Mac OS X can be picky when it comes to allowing the user to use physical 
> devices
> in QEMU. Most mounted volumes appear to be off limits to QEMU. If an issue is
> detected, a message is displayed showing the user how to unmount a volume.
> 
> Signed-off-by: John Arbuckle 
> 
> ---
> Removed changes to GetBSDPath() to a separate patch.
> This patch now depends on the GetBSDPath patch.
> 
>  block/raw-posix.c |   90 +---
>  1 files changed, 64 insertions(+), 26 deletions(-)
> 
> diff --git a/block/raw-posix.c b/block/raw-posix.c
> index 67d1d48..a41006f 100644
> --- a/block/raw-posix.c
> +++ b/block/raw-posix.c
> @@ -42,9 +42,8 @@
>  #include 
>  #include 
>  #include 
> -//#include 
>  #include 
> -#endif
> +#endif /* (__APPLE__) && (__MACH__) */
>  
>  #ifdef __sun__
>  #define _POSIX_PTHREAD_SEMANTICS 1
> @@ -1972,7 +1971,7 @@ BlockDriver bdrv_file = {
>  /* host device */
>  
>  #if defined(__APPLE__) && defined(__MACH__)
> -static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
> +static kern_return_t FindEjectableCDMedia(io_iterator_t *mediaIterator);
>  static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
>  CFIndex maxPathSize, int flags);
>  kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator )
> @@ -2030,7 +2029,34 @@ kern_return_t GetBSDPath(io_iterator_t mediaIterator, 
> char *bsdPath,
>  return kernResult;
>  }
>  
> -#endif
> +/* Sets up a real cdrom for use in QEMU */
> +static bool setupCDROM(char *bsdPath)
> +{
> +int index, numOfTestPartitions = 2, fd;
> +char testPartition[MAXPATHLEN];
> +bool partitionFound = false;
> +
> +/* look for a working partition */
> +for (index = 0; index < numOfTestPartitions; index++) {
> +snprintf(testPartition, sizeof(testPartition), "%ss%d", bsdPath, 
> index);
> +fd = qemu_open(testPartition, O_RDONLY | O_BINARY | O_LARGEFILE);
> +if (fd >= 0) {
> +partitionFound = true;
> +qemu_close(fd);
> +break;
> +}
> +}
> +
> +/* if a working partition on the device was not found */
> +if (partitionFound == false) {
> +printf("Error: Failed to find a working partition on disc!\n");
> +} else {
> +DPRINTF("Using %s as optical disc\n", testPartition);
> +pstrcpy(bsdPath, MAXPATHLEN, testPartition);
> +}
> +return partitionFound;
> +}
> +#endif /* defined(__APPLE__) && defined(__MACH__) */
>  
>  static int hdev_probe_device(const char *filename)
>  {
> @@ -2118,34 +2144,32 @@ static int hdev_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  BDRVRawState *s = bs->opaque;
>  Error *local_err = NULL;
>  int ret;
> +bool cdromOK = true;
>  
>  #if defined(__APPLE__) && defined(__MACH__)
>  const char *filename = qdict_get_str(options, "filename");
>  
> -if (strstart(filename, "/dev/cdrom", NULL)) {
> -kern_return_t kernResult;
> -io_iterator_t mediaIterator;
> -char bsdPath[ MAXPATHLEN ];
> -int fd;
> -
> -kernResult = FindEjectableCDMedia( &mediaIterator );
> -kernResult = GetBSDPath(mediaIterator, bsdPath, sizeof(bsdPath), 
> -
> flags);
> -if ( bsdPath[ 0 ] != '\0' ) {
> -strcat(bsdPath,"s0");
> -/* some CDs don't have a partition 0 */
> -fd = qemu_open(bsdPath, O_RDONLY | O_BINARY | O_LARGEFILE);
> -if (fd < 0) {
> -bsdPath[strlen(bsdPath)-1] = '1';
> +/* If using a physical device */
> +if (strstart(filename, "/dev/", NULL)) {
> +char bsdPath[MAXPATHLEN];
> +
> +/* If the physical device is a cdrom */
> +if (strcmp(filename, "/dev/cdrom") == 0) {
> +io_iterator_t mediaIterator;
> +FindEjectableCDMedia(&mediaIterator);
> +GetBSDPath(mediaIterator, bsdPath, sizeof(bsdPath), flags);
> +if (bsdPath[0] == '\0') {
> +printf("Error: failed to obtain bsd path for optical 
> drive!\n");
>  } else {
> -qemu_close(fd);
> +cdromOK = setupCDROM(bsdPath);
> +filename = bsdPath;
>  }
> -filename = bsdPath;
> -qdict_put(options, "filename", qstring_from_str(filename));
> -}
>  
> -if ( mediaIterator )
> -IOObjectRelease( mediaIterator );
> +if (mediaIterator) {
> +IOObjectRelease(mediaIterator);
> +}
> +}
> +qdict_put(options, "filename", qstring_from_str(filename));
>  }
>  #endif
>  
> @@ -2156,7 +2180,21 @@ static int hdev_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  if (local_err) {

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 27, 2015, at 10:30 PM, Michael Roth wrote:

> Quoting Programmingkid (2015-09-27 20:49:24)
>> 
>> On Sep 27, 2015, at 2:53 PM, Peter Crosthwaite wrote:
>> 
>>> On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell  
>>> wrote:
>>>> On 27 September 2015 at 04:39, Programmingkid  
>>>> wrote:
>>>>> Would you be open to a feature that allows the user to select
>>>>> and run a custom file that has commands in it that would run
>>>>> in the monitor?
>>>> 
>>>> Sounds like a VM management layer feature.
>>>> 
>>> 
>>> Should -monitor file:/foo/bar do something like this?
>> 
>> If you are saying this command line argument loads monitor commands,
>> then it would only work when QEMU is first started. The feature I want
>> would work anytime during the running of QEMU. 
> 
> For that sort of flexibility I think writing commands to a socket via
> a script/program is simple enough that an additional interface doesn't
> seem worthwhile. Even our qtest unit tests use this approach. Plus you
> get the flexibility of a being able to branch based on the return
> value of commands (error-handling, stateful commands, incorporating
> output from a serial console, etc.). It seems like a nice feature but
> it's vastly inferior to what's possible with an external driver.

How many people know how to communicate with QEMU via a socket?
How do you even do it? It doesn't sound very easy to do. A menu item
that displays a file open dialog is very easy to use. The user just selects
a file and QEMU loads and runs all the commands in it. This feature
would make QEMU easier to use. It would also make QEMU easily
expandable. Typing long commands in the monitor is difficult and
error prone. Saving these commands in a file would make it much
easier for the user. An example command someone could put in a
file is sending Control-Alt-Delete to the emulator. Another command
could be mounting an image file. This feature would make things
much easier for the user.

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 27, 2015, at 2:53 PM, Peter Crosthwaite wrote:

> On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell  
> wrote:
>> On 27 September 2015 at 04:39, Programmingkid  
>> wrote:
>>> Would you be open to a feature that allows the user to select
>>> and run a custom file that has commands in it that would run
>>> in the monitor?
>> 
>> Sounds like a VM management layer feature.
>> 
> 
> Should -monitor file:/foo/bar do something like this?

If you are saying this command line argument loads monitor commands,
then it would only work when QEMU is first started. The feature I want
would work anytime during the running of QEMU. 

[Qemu-devel] [PATCH] ui/cocoa.m: fix help menus

[Programmingkid]

Make the help menus actually work. 

Signed-off-by: John Arbuckle 

---
 ui/cocoa.m |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..2c81785 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -992,16 +992,28 @@ QemuCocoaView *cocoaView;
 {
 COCOA_DEBUG("QemuCocoaAppController: showQEMUDoc\n");
 
-[[NSWorkspace sharedWorkspace] openFile:[NSString 
stringWithFormat:@"%@/../doc/qemu/qemu-doc.html",
-[[NSBundle mainBundle] resourcePath]] withApplication:@"Help Viewer"];
+NSString *path;
+path = [[NSBundle mainBundle] resourcePath];
+path = [path stringByDeletingLastPathComponent];
+path = [NSString stringWithFormat: @"%@/%s", path, "qemu-doc.html"];
+if([[NSWorkspace sharedWorkspace] openFile: path] == NO) {
+NSBeep();
+QEMU_Alert(@"Failed to open file qemu-doc.html!");
+}
 }
 
 - (void)showQEMUTec:(id)sender
 {
 COCOA_DEBUG("QemuCocoaAppController: showQEMUTec\n");
 
-[[NSWorkspace sharedWorkspace] openFile:[NSString 
stringWithFormat:@"%@/../doc/qemu/qemu-tech.html",
-[[NSBundle mainBundle] resourcePath]] withApplication:@"Help Viewer"];
+NSString *path;
+path = [[NSBundle mainBundle] resourcePath];
+path = [path stringByDeletingLastPathComponent];
+path = [NSString stringWithFormat: @"%@/%s", path, "qemu-tech.html"];
+if([[NSWorkspace sharedWorkspace] openFile: path] == NO) {
+NSBeep();
+QEMU_Alert(@"Failed to open file qemu-tech.html!");
+}
 }
 
 /* Stretches video to fit host monitor size */
-- 
1.7.5.4

[Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

Would you be open to a feature that allows the user to select and run a custom 
file that has commands in it that would run in the monitor? 

[Qemu-devel] [PATCH] ui/cocoa.m: blinky mouse cursor fix

[Programmingkid]

The mouse cursor can become blinky when being moved a lot. This patch fixes that
problem by issuing the redraw sooner. 

Signed-off-by: John Arbuckle 

---
 ui/cocoa.m |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..cf372a4 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -1275,6 +1275,7 @@ static void cocoa_refresh(DisplayChangeListener *dcl)
 NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
 
 COCOA_DEBUG("qemu_cocoa: cocoa_refresh\n");
+graphic_hw_update(NULL);
 
 if (qemu_input_is_absolute()) {
 if (![cocoaView isAbsoluteEnabled]) {
@@ -1295,7 +1296,6 @@ static void cocoa_refresh(DisplayChangeListener *dcl)
 [cocoaView handleEvent:event];
 }
 } while(event != nil);
-graphic_hw_update(NULL);
 [pool release];
 }
 
-- 
1.7.5.4

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Add real CDROM menu item

[Programmingkid]

On Sep 26, 2015, at 6:49 PM, Namsun Ch'o wrote:

>> Actually on Mac OS X, /dev/cdrom always points to the optical drive.
>> It is how QEMU is programmed.
> 
> Is this only for Mac? I must have missed that.

Yes, it is for the Macintosh's cocoa interface.

Re: [Qemu-devel] [PATCH] ui/cocoa.m: Add real CDROM menu item

[Programmingkid]

On Sep 26, 2015, at 1:45 AM, Namsun Ch'o wrote:

>> Add a menu item to the Machine menu called "Use Real CDROM". It gives the
>> user the ability to use a real CDROM with QEMU by simply selecting a menu
>> item.
> 
>> NSASCIIStringEncoding];
>> +qmp_change_blockdev(device, "/dev/cdrom", "raw", &err);
>> +handleAnyDeviceErrors(err);
> 
> Not all systems put their CDROM in /dev/cdrom. And you can already select the
> machine's real CDROM hardware by doing -cdrom /dev/cdrom (or /dev/sr0, etc).
> Examples of device files for CDROMs on other systems:
> 
> /dev/sr0
> /dev/cd0
> /dev/sdc0
> /dev/acd0c
> /dev/cdrom0
> /dev/disk1s0
> /dev/scsi/sc0d
> /dev/dsk/c1t0d0s0
> /dev/rdsk/dks0d1vh
> 
> And of course many of the numbers here increment on systems with multiple
> drives. There is seriously an insane amount of variation of the names of CDROM
> drives. Don't assume that it will only be /dev/cdrom and hardcode it that way.


Actually on Mac OS X, /dev/cdrom always points to the optical drive. It is how 
QEMU is programmed.

[Qemu-devel] [PATCH] ui/cocoa.m: Add real CDROM menu item

[Programmingkid]

Add a menu item to the Machine menu called "Use Real CDROM". It gives the user
the ability to use a real CDROM disc with QEMU by simply selecting a menu item.

Signed-off-by: John Arbuckle 

---
 ui/cocoa.m |   87 
 1 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..7586ba3 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -829,6 +829,7 @@ QemuCocoaView *cocoaView;
 - (void)powerDownQEMU:(id)sender;
 - (void)ejectDeviceMedia:(id)sender;
 - (void)changeDeviceMedia:(id)sender;
+- (void)useRealCDROM:(id)sender;
 @end
 
 @implementation QemuCocoaAppController
@@ -1125,6 +1126,16 @@ QemuCocoaView *cocoaView;
 }
 }
 
+/* Has QEMU use the real CDROM drive */
+- (void)useRealCDROM:(id)sender
+{
+Error *err = NULL;
+const char *device = [[sender representedObject] cStringUsingEncoding:
+ 
NSASCIIStringEncoding];
+qmp_change_blockdev(device, "/dev/cdrom", "raw", &err);
+handleAnyDeviceErrors(err);
+}
+
 @end
 
 
@@ -1338,6 +1349,79 @@ static void add_console_menu_entries(void)
 }
 }
 
+/*
+ * Determines if the emulator has a CDROM drive.
+ * Can only be called after the addRemovableDevicesMenuItems() function has 
been
+ * called.
+ */
+static bool emulatorHasCDROM(void)
+{
+int index;
+NSString *title;
+NSArray *menu_item_array;
+NSMenu *menu;
+menu = [[[NSApp mainMenu] itemWithTitle:@"Machine"] submenu];
+menu_item_array = [menu itemArray];
+if (!menu_item_array) {
+NSBeep();
+QEMU_Alert(@"Failed to obtain Machine menu items!");
+return false;
+}
+/* Start at the first removable device menu item */
+for (index = 7; index < [menu_item_array count]; index++) {
+title = [[menu_item_array objectAtIndex: index] title];
+if ([title rangeOfString: @"cd"].location != NSNotFound) {
+return true;
+}
+}
+return false;
+}
+
+/* Find the CDROM's name */
+static NSString *getCDName(void)
+{
+int index, end_of_string_index;
+NSString *title, *return_value;
+NSArray *menu_item_array;
+NSMenu *menu = [[[NSApp mainMenu] itemWithTitle:@"Machine"] submenu];
+menu_item_array = [menu itemArray];
+if (!menu_item_array) {
+NSBeep();
+QEMU_Alert(@"Failed to obtain Machine menu items!");
+return nil;
+}
+/* Start at the first removable device menu item */
+for (index = 7; index < [menu_item_array count]; index++) {
+title = [[menu_item_array objectAtIndex: index] title];
+if ([title rangeOfString: @"cd"].location != NSNotFound) {
+return_value = [[title componentsSeparatedByString: @" "]
+  objectAtIndex: 
1];
+end_of_string_index = [return_value rangeOfString: @"."].location;
+return_value = [return_value substringToIndex: 
end_of_string_index];
+return return_value;
+}
+}
+return nil;
+}
+
+/* Add the "Use Real CDROM" menu item */
+static void addRealCDMenuItem(void)
+{
+NSMenu *machine_menu;
+NSMenuItem *menu_item;
+machine_menu = [[[NSApp mainMenu] itemWithTitle:@"Machine"] submenu];
+if (!machine_menu) {
+NSBeep();
+QEMU_Alert(@"Could not find Machine Menu!");
+return;
+}
+menu_item = [[NSMenuItem alloc] initWithTitle: @"Use Real CDROM"
+  action: @selector(useRealCDROM:)
+   keyEquivalent: @""];
+[menu_item setRepresentedObject: getCDName()];
+[machine_menu insertItem: menu_item atIndex: 7];
+}
+
 /* Make menu items for all removable devices.
  * Each device is given an 'Eject' and 'Change' menu item.
  */
@@ -1433,4 +1517,7 @@ void cocoa_display_init(DisplayState *ds, int full_screen)
  * find out what removable devices it has.
  */
 addRemovableDevicesMenuItems();
+if(emulatorHasCDROM()) {
+addRealCDMenuItem();
+}
 }
-- 
1.7.5.4

[Qemu-devel] [PATCH] ui/cocoa.m: addRemovableDevicesMenuItems() warning fix

[Programmingkid]

Eliminate this warning associated with the addRemovableDevicesMenuItems()
function:

ui/cocoa.m:1344:13: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
 static void addRemovableDevicesMenuItems()
 ^
ui/cocoa.m: In function 'addRemovableDevicesMenuItems':
ui/cocoa.m:1344:13: warning: old-style function definition 
[-Wold-style-definition]


Signed-off-by: John Arbuckle 

---
 ui/cocoa.m |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..a94cc68 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -1341,7 +1341,7 @@ static void add_console_menu_entries(void)
 /* Make menu items for all removable devices.
  * Each device is given an 'Eject' and 'Change' menu item.
  */
-static void addRemovableDevicesMenuItems()
+static void addRemovableDevicesMenuItems(void)
 {
 NSMenu *menu;
 NSMenuItem *menuItem;
-- 
1.7.5.4

[Qemu-devel] [PATCH] ui/cocoa.m: eliminate normalWindow warning

[Programmingkid]

Eliminate this warning associated with the setting of the normalWindow's title:

ui/cocoa.m: In function '-[QemuCocoaAppController init]':
ui/cocoa.m:888:9: warning: format not a string literal and no format arguments
 [-Wformat-security]
 [normalWindow setTitle:[NSString stringWithFormat:@"QEMU"]];


Signed-off-by: John Arbuckle 

---
 ui/cocoa.m |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..fa21fdb 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -855,7 +855,7 @@ QemuCocoaView *cocoaView;
 exit(1);
 }
 [normalWindow setAcceptsMouseMovedEvents:YES];
-[normalWindow setTitle:[NSString stringWithFormat:@"QEMU"]];
+[normalWindow setTitle:@"QEMU"];
 [normalWindow setContentView:cocoaView];
 #if (MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_10)
 [normalWindow useOptimizedDrawing:YES];
-- 
1.7.5.4

Re: [Qemu-devel] [PATCH] ui/cocoa.m: remove open dialog code

[Programmingkid]

On Sep 25, 2015, at 6:00 PM, Peter Maydell wrote:

> On 25 September 2015 at 14:00, Programmingkid  
> wrote:
>> Removes the open dialog code that runs when no arguments are supplied with 
>> QEMU.
>> Not everyone needs a hard drive or cdrom to boot their target. A user might 
>> only
>> need to use their target's bios to do work. With that said, this patch 
>> removes
>> the unneeded open dialog code.
>> 
>> Signed-off-by: John Arbuckle 
> 
> Applied to cocoa.next, thanks.
> 
> Do you have more patches pending or is now a good time to flush
> the cocoa.next queue to master?

There is the patch that allows the user to use a real CD-ROM disc in
QEMU. It adds a menu item to the Machine menu called "Use real cdrom".
The problem is it wouldn't work because the patch I made to fix access
problems with real CD-ROM disk might not be applied to QEMU yet. It
was sent to Kevin Wolf back in July. Haven't heard back from him yet. 

[Qemu-devel] [PATCH] ui/cocoa.m: remove open dialog code

[Programmingkid]

Removes the open dialog code that runs when no arguments are supplied with QEMU.
Not everyone needs a hard drive or cdrom to boot their target. A user might only
need to use their target's bios to do work. With that said, this patch removes
the unneeded open dialog code. 

Signed-off-by: John Arbuckle 

---
 ui/cocoa.m |   56 ++--
 1 files changed, 2 insertions(+), 54 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..1dc9bc6 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -814,7 +814,6 @@ QemuCocoaView *cocoaView;
 {
 }
 - (void)startEmulationWithArgc:(int)argc argv:(char**)argv;
-- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode 
contextInfo:(void *)contextInfo;
 - (void)doToggleFullScreen:(id)sender;
 - (void)toggleFullScreen:(id)sender;
 - (void)showQEMUDoc:(id)sender;
@@ -895,29 +894,8 @@ QemuCocoaView *cocoaView;
 - (void)applicationDidFinishLaunching: (NSNotification *) note
 {
 COCOA_DEBUG("QemuCocoaAppController: applicationDidFinishLaunching\n");
-
-// Display an open dialog box if no arguments were passed or
-// if qemu was launched from the finder ( the Finder passes "-psn" )
-if( gArgc <= 1 || strncmp ((char *)gArgv[1], "-psn", 4) == 0) {
-NSOpenPanel *op = [[NSOpenPanel alloc] init];
-[op setPrompt:@"Boot image"];
-[op setMessage:@"Select the disk image you want to boot.\n\nHit the 
\"Cancel\" button to quit"];
-#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6)
-[op setAllowedFileTypes:supportedImageFileTypes];
-[op beginSheetModalForWindow:normalWindow
-completionHandler:^(NSInteger returnCode)
-{ [self openPanelDidEnd:op
-  returnCode:returnCode contextInfo:NULL ]; } ];
-#else
-// Compatibility code for pre-10.6, using deprecated method
-[op beginSheetForDirectory:nil file:nil types:filetypes
-  modalForWindow:normalWindow modalDelegate:self
-  
didEndSelector:@selector(openPanelDidEnd:returnCode:contextInfo:) 
contextInfo:NULL];
-#endif
-} else {
-// or launch QEMU, with the global args
-[self startEmulationWithArgc:gArgc argv:(char **)gArgv];
-}
+// launch QEMU, with the global args
+[self startEmulationWithArgc:gArgc argv:(char **)gArgv];
 }
 
 - (void)applicationWillTerminate:(NSNotification *)aNotification
@@ -942,36 +920,6 @@ QemuCocoaView *cocoaView;
 exit(status);
 }
 
-- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode 
contextInfo:(void *)contextInfo
-{
-COCOA_DEBUG("QemuCocoaAppController: openPanelDidEnd\n");
-
-/* The NSFileHandlingPanelOKButton/NSFileHandlingPanelCancelButton values 
for
- * returnCode strictly only apply for the 10.6-and-up 
beginSheetModalForWindow
- * API. For the legacy pre-10.6 beginSheetForDirectory API they are 
NSOKButton
- * and NSCancelButton. However conveniently the values are the same.
- * We use the non-legacy names because the others are deprecated in OSX 
10.10.
- */
-if (returnCode == NSFileHandlingPanelCancelButton) {
-exit(0);
-} else if (returnCode == NSFileHandlingPanelOKButton) {
-char *img = (char*)[ [ [ sheet URL ] path ] 
cStringUsingEncoding:NSASCIIStringEncoding];
-
-char **argv = g_new(char *, 4);
-
-[sheet close];
-
-argv[0] = g_strdup(gArgv[0]);
-argv[1] = g_strdup("-hda");
-argv[2] = g_strdup(img);
-argv[3] = NULL;
-
-// printf("Using argc %d argv %s -hda %s\n", 3, gArgv[0], img);
-
-[self startEmulationWithArgc:3 argv:(char**)argv];
-}
-}
-
 /* We abstract the method called by the Enter Fullscreen menu item
  * because Mac OS 10.7 and higher disables it. This is because of the
  * menu item's old selector's name toggleFullScreen:
-- 
1.7.5.4

Re: [Qemu-devel] [PATCH v2] ui/cocoa.m: remove open dialog code

[Programmingkid]

On Sep 25, 2015, at 4:14 PM, Peter Maydell wrote:

> On 25 September 2015 at 12:58, Programmingkid  
> wrote:
>> 
>> On Sep 25, 2015, at 2:53 PM, Peter Maydell wrote:
>> 
>>> On 25 September 2015 at 11:24, Programmingkid  
>>> wrote:
>>> 
>>>> I don't think Mac OS X adds the -psn argument anymore. It might have
>>>> in the past, but I don't see any sign of it on Mac OS 10.6. I made
>>>> a test program and launched it from both the terminal and the Finder.
>>>> I didn't see the -psn argument.
>>> 
>>> Hmm, you're right. Googling suggests that the -psn argument is added
>>> only if the program is in an 'application bundle' (ie not just a
>>> bare executable).
>>> 
>>> So that means we can't easily distinguish being run from the GUI
>>> vs from the command line, which means we don't have a convenient
>>> way to check for whether we should bring up that dialog box.
>>> 
>>> I think that brings us back to somewhere near your first patch --
>>> just remove the dialog box code. If anybody is somehow running
>>> QEMU in an application bundle they'll let us know that it's broken,
>>> I'm sure :-)
>>> 
>>> Sorry for all the back-and-forth on this patch. Can you send out
>>> a v3 that goes back to that approach, please?
>>> 
>>> -- PMM
>> 
>> I think you want this patch (the original one):
> 
> Yes, but I was hoping for it in a format that works with
> our patch-handling tools...

What needs to be changed to make it work with the patch-handling tools?

Re: [Qemu-devel] [PATCH v2] ui/cocoa.m: remove open dialog code

[Programmingkid]

On Sep 25, 2015, at 2:53 PM, Peter Maydell wrote:

> On 25 September 2015 at 11:24, Programmingkid  
> wrote:
> 
>> I don't think Mac OS X adds the -psn argument anymore. It might have
>> in the past, but I don't see any sign of it on Mac OS 10.6. I made
>> a test program and launched it from both the terminal and the Finder.
>> I didn't see the -psn argument.
> 
> Hmm, you're right. Googling suggests that the -psn argument is added
> only if the program is in an 'application bundle' (ie not just a
> bare executable).
> 
> So that means we can't easily distinguish being run from the GUI
> vs from the command line, which means we don't have a convenient
> way to check for whether we should bring up that dialog box.
> 
> I think that brings us back to somewhere near your first patch --
> just remove the dialog box code. If anybody is somehow running
> QEMU in an application bundle they'll let us know that it's broken,
> I'm sure :-)
> 
> Sorry for all the back-and-forth on this patch. Can you send out
> a v3 that goes back to that approach, please?
> 
> -- PMM

I think you want this patch (the original one):

Subject: [PATCH] ui/cocoa.m: remove open dialog code 

Removes the open dialog code that runs when no arguments are supplied with QEMU.
Not everyone needs a hard drive or cdrom to boot their target. A user might only
need to use their target's bios to do work. With that said, this patch removes
the unneeded open dialog code. 

Signed-off-by: John Arbuckle 

---
 ui/cocoa.m |   56 ++--
 1 files changed, 2 insertions(+), 54 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..1dc9bc6 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -814,7 +814,6 @@ QemuCocoaView *cocoaView;
 {
 }
 - (void)startEmulationWithArgc:(int)argc argv:(char**)argv;
-- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode 
contextInfo:(void *)contextInfo;
 - (void)doToggleFullScreen:(id)sender;
 - (void)toggleFullScreen:(id)sender;
 - (void)showQEMUDoc:(id)sender;
@@ -895,29 +894,8 @@ QemuCocoaView *cocoaView;
 - (void)applicationDidFinishLaunching: (NSNotification *) note
 {
 COCOA_DEBUG("QemuCocoaAppController: applicationDidFinishLaunching\n");
-
-// Display an open dialog box if no arguments were passed or
-// if qemu was launched from the finder ( the Finder passes "-psn" )
-if( gArgc <= 1 || strncmp ((char *)gArgv[1], "-psn", 4) == 0) {
-NSOpenPanel *op = [[NSOpenPanel alloc] init];
-[op setPrompt:@"Boot image"];
-[op setMessage:@"Select the disk image you want to boot.\n\nHit the 
\"Cancel\" button to quit"];
-#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6)
-[op setAllowedFileTypes:supportedImageFileTypes];
-[op beginSheetModalForWindow:normalWindow
-completionHandler:^(NSInteger returnCode)
-{ [self openPanelDidEnd:op
-  returnCode:returnCode contextInfo:NULL ]; } ];
-#else
-// Compatibility code for pre-10.6, using deprecated method
-[op beginSheetForDirectory:nil file:nil types:filetypes
-  modalForWindow:normalWindow modalDelegate:self
-  
didEndSelector:@selector(openPanelDidEnd:returnCode:contextInfo:) 
contextInfo:NULL];
-#endif
-} else {
-// or launch QEMU, with the global args
-[self startEmulationWithArgc:gArgc argv:(char **)gArgv];
-}
+// launch QEMU, with the global args
+[self startEmulationWithArgc:gArgc argv:(char **)gArgv];
 }
 
 - (void)applicationWillTerminate:(NSNotification *)aNotification
@@ -942,36 +920,6 @@ QemuCocoaView *cocoaView;
 exit(status);
 }
 
-- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode 
contextInfo:(void *)contextInfo
-{
-COCOA_DEBUG("QemuCocoaAppController: openPanelDidEnd\n");
-
-/* The NSFileHandlingPanelOKButton/NSFileHandlingPanelCancelButton values 
for
- * returnCode strictly only apply for the 10.6-and-up 
beginSheetModalForWindow
- * API. For the legacy pre-10.6 beginSheetForDirectory API they are 
NSOKButton
- * and NSCancelButton. However conveniently the values are the same.
- * We use the non-legacy names because the others are deprecated in OSX 
10.10.
- */
-if (returnCode == NSFileHandlingPanelCancelButton) {
-exit(0);
-} else if (returnCode == NSFileHandlingPanelOKButton) {
-char *img = (char*)[ [ [ sheet URL ] path ] 
cStringUsingEncoding:NSASCIIStringEncoding];
-
-char **argv = g_new(char *, 4);
-
-[sheet close];
-
-argv[0] = g_strdup(gArgv[0]);
-argv[1] = g_strdup("-hda");
-argv[2] = g_strdup(img);
-argv[3] = NULL;
-
-// printf("Usi

Re: [Qemu-devel] [PATCH v2] ui/cocoa.m: remove open dialog code

[Programmingkid]

On Sep 25, 2015, at 12:21 PM, Peter Maydell wrote:

> On 25 September 2015 at 09:12, Programmingkid  
> wrote:
>> 
>> On Sep 25, 2015, at 12:09 PM, Peter Maydell wrote:
>>> (Also, isn't a simple test on gArgc going to cause us to put up
>>> the dialog box even if qemu was started from the command line with
>>> no arguments?)
>> 
>> I suppose you are right. Will make a new patch to fix this problem.
> 
> Given that that was the problem you were trying to address with
> these patches in the first place, it would be a good idea to test
> that your changes do now let you do what you wanted...
> 
> -- PMM

I don't think Mac OS X adds the -psn argument anymore. It might have in the 
past, but I don't see any sign of it on Mac OS 10.6. I made a test program and 
launched it from both the terminal and the Finder. I didn't see the -psn 
argument. 

Do you see -psn with this program?

#include 

int main(int argc, char *argv[])
{
int i;
printf("argc = %d\n", argc);
for(i = 0; i < argc; i++) {
printf("arg %d = %s\n", i, argv[i]);
}
printf("done\n");
return 0;
}

[Qemu-devel] [PATCH v3] ui/cocoa.m: remove open dialog code

[Programmingkid]

Removes the open dialog code that runs when no arguments
are supplied with QEMU. Not everyone needs a hard drive
or cdrom to boot their target. A user might only need to
use their target's bios to do work. With that said,
this patch removes the unneeded open dialog code. 
Signed-off-by: John Arbuckle 

---
Adds checking for the -psn argument.

 ui/cocoa.m |   66 ---
 1 files changed, 14 insertions(+), 52 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..adceaaa 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -814,7 +814,6 @@ QemuCocoaView *cocoaView;
 {
 }
 - (void)startEmulationWithArgc:(int)argc argv:(char**)argv;
-- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode 
contextInfo:(void *)contextInfo;
 - (void)doToggleFullScreen:(id)sender;
 - (void)toggleFullScreen:(id)sender;
 - (void)showQEMUDoc:(id)sender;
@@ -896,27 +895,20 @@ QemuCocoaView *cocoaView;
 {
 COCOA_DEBUG("QemuCocoaAppController: applicationDidFinishLaunching\n");
 
-// Display an open dialog box if no arguments were passed or
-// if qemu was launched from the finder ( the Finder passes "-psn" )
-if( gArgc <= 1 || strncmp ((char *)gArgv[1], "-psn", 4) == 0) {
-NSOpenPanel *op = [[NSOpenPanel alloc] init];
-[op setPrompt:@"Boot image"];
-[op setMessage:@"Select the disk image you want to boot.\n\nHit the 
\"Cancel\" button to quit"];
-#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6)
-[op setAllowedFileTypes:supportedImageFileTypes];
-[op beginSheetModalForWindow:normalWindow
-completionHandler:^(NSInteger returnCode)
-{ [self openPanelDidEnd:op
-  returnCode:returnCode contextInfo:NULL ]; } ];
-#else
-// Compatibility code for pre-10.6, using deprecated method
-[op beginSheetForDirectory:nil file:nil types:filetypes
-  modalForWindow:normalWindow modalDelegate:self
-  
didEndSelector:@selector(openPanelDidEnd:returnCode:contextInfo:) 
contextInfo:NULL];
-#endif
-} else {
-// or launch QEMU, with the global args
-[self startEmulationWithArgc:gArgc argv:(char **)gArgv];
+// if the user launched QEMU from the Finder
+if (gArgc <= 1 || strncmp(gArgv[1], "-psn", 4) == 0) {
+NSAlert *alert = [NSAlert new];
+[alert autorelease];
+[alert setMessageText: @"Please start QEMU from the command line with"
+  " appropriate 
arguments"];
+[alert addButtonWithTitle: @"Quit"];
+[alert addButtonWithTitle: @"Continue"];
+if([alert runModal] == NSAlertFirstButtonReturn) {
+[NSApp terminate: self];
+} else {
+// launch QEMU, with the global args
+[self startEmulationWithArgc:gArgc argv:(char **)gArgv];
+}
 }
 }
 
@@ -942,36 +934,6 @@ QemuCocoaView *cocoaView;
 exit(status);
 }
 
-- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode 
contextInfo:(void *)contextInfo
-{
-COCOA_DEBUG("QemuCocoaAppController: openPanelDidEnd\n");
-
-/* The NSFileHandlingPanelOKButton/NSFileHandlingPanelCancelButton values 
for
- * returnCode strictly only apply for the 10.6-and-up 
beginSheetModalForWindow
- * API. For the legacy pre-10.6 beginSheetForDirectory API they are 
NSOKButton
- * and NSCancelButton. However conveniently the values are the same.
- * We use the non-legacy names because the others are deprecated in OSX 
10.10.
- */
-if (returnCode == NSFileHandlingPanelCancelButton) {
-exit(0);
-} else if (returnCode == NSFileHandlingPanelOKButton) {
-char *img = (char*)[ [ [ sheet URL ] path ] 
cStringUsingEncoding:NSASCIIStringEncoding];
-
-char **argv = g_new(char *, 4);
-
-[sheet close];
-
-argv[0] = g_strdup(gArgv[0]);
-argv[1] = g_strdup("-hda");
-argv[2] = g_strdup(img);
-argv[3] = NULL;
-
-// printf("Using argc %d argv %s -hda %s\n", 3, gArgv[0], img);
-
-[self startEmulationWithArgc:3 argv:(char**)argv];
-}
-}
-
 /* We abstract the method called by the Enter Fullscreen menu item
  * because Mac OS 10.7 and higher disables it. This is because of the
  * menu item's old selector's name toggleFullScreen:
-- 
1.7.5.4

Re: [Qemu-devel] [PATCH v3] ui/cocoa.m: Add Mount image file menu item

[Programmingkid]

On Sep 25, 2015, at 11:42 AM, Markus Armbruster wrote:

> Programmingkid  writes:
> 
>> On Sep 24, 2015, at 2:57 AM, Markus Armbruster wrote:
>> 
>>> Programmingkid  writes:
>>> 
>>>> On Sep 23, 2015, at 4:35 PM, Peter Maydell wrote:
>>>> 
>>>>> On 17 September 2015 at 21:17, Programmingkid
>>>>>  wrote:
>>>>>> Add "Mount Image File..." and a "Eject Image File" menu items to
>>>>>> cocoa interface. This patch makes sharing files between the
>>>>>> host and the guest user-friendly.
>>>>>> 
>>>>>> The "Mount Image File..." menu item displays a dialog box having the
>>>>>> user pick an image file to use in QEMU. The image file is setup as
>>>>>> a USB flash drive. The user can do the equivalent of removing the
>>>>>> flash drive by selecting the file in the "Eject Image File" submenu.
>>>>>> 
>>>>>> Signed-off-by: John Arbuckle 
>>>>> 
>>>>> I've thought a bit about this, and I really don't think this sort
>>>>> of feature should be part of QEMU itself. Our general design for
>>>>> how QEMU does this sort of thing is that an external program
>>>>> (virt-manager, for instance) is responsible for providing most
>>>>> of the UI conveniences the user wants, and QEMU's "ui" code is
>>>>> a fairly simple minimum-functionality affair. I agree with Markus
>>>>> that this separation of concerns has generally worked OK for us.
>>>>> 
>>>>> I don't think OSX should be an exception to this design model:
>>>>> (a) being an odd special case is never a good idea
>>>>> (b) as a practical matter, I'm the only person who really reviews
>>>>> OSX patches, and I don't have either the time nor the UI or OSX
>>>>> expertise to deal with maintaining what will effectively be a
>>>>> vm-manager grafted onto the side of QEMU
>>>>> 
>>>>> So I think your efforts would be better spent in either porting
>>>>> one of the Linux frontends like libvirt/virt-manager, or in
>>>>> writing a custom OSX specific frontend.
>>>> 
>>>> I understand that time is precious. It is one of those things
>>>> that we only have a finite amount of. Every user can agree
>>>> to that. This patch was pretty hairy looking with the QDict
>>>> and other unfamiliar code. With that said I'm not ready to
>>>> give up on this patch. It is a huge time saver for the user.
>>>> Without it, the user would need to spend a lot of time
>>>> investigating documentation. What's worse is the user
>>>> would have to type out full paths to files they need. This
>>>> would definitely be error prone and frustrating.
>>> 
>>> Nobody is challenging the idea that many users appreciate a GUI.
>>> 
>>> What we've been trying to tell you is where in this software layer cake
>>> the GUI should be.  In Peter's words, "our general design for how QEMU
>>> does this sort of thing is that an external program (virt-manager, for
>>> instance) is responsible for providing most of the UI conveniences".
>> 
>> That is easy for you to say. Linux already has virt-manager. Mac OS X 
>> doesn't. 
>> Expecting someone to just go and port another program to Mac OS X is 
>> unreasonable. The amount of time and energy it would take to do so
>> would make it hard. 
> 
> On the purely technical level, it may or may not be harder than mashing
> everything into QEMU.
> 
> On the getting-patches-merged level, mashing everything into QEMU is a
> non-starter, as Peter and I have told you multiple times.
> 
> That tips the balance somewhat.
> 
>>>> This patch can definitely be more simplified. QMP
>>>> commands could be used in place of C functions. 
>>>> This would reduce the patch size greatly. 
>>> 
>>> You're quite welcome to use QMP the way it wants to be used: as an
>>> external interface.
>>> 
>>> Abusing it as internal interface won't fly.
>> 
>> The QMP interface is primarily there to help a gui interact with QEMU. That
>> is what I intend to use it for.
> 
> Nope, the QMP interface's purpose is to let other programs interact with
> QEMU.
> 
> You're free to use it for other purposes to your heart's content.  Just
> don't count on patches to be merged when they do things maintainers have
> told you not to do :)

I did do as you said and used C functions in place of the original hmp 
commands. 
I guess there never was any hope for this patch. :(

Re: [Qemu-devel] [PATCH v3] ui/cocoa.m: Add Mount image file menu item

[Programmingkid]

On Sep 23, 2015, at 4:35 PM, Peter Maydell wrote:

> On 17 September 2015 at 21:17, Programmingkid  
> wrote:
>> Add "Mount Image File..." and a "Eject Image File" menu items to
>> cocoa interface. This patch makes sharing files between the
>> host and the guest user-friendly.
>> 
>> The "Mount Image File..." menu item displays a dialog box having the
>> user pick an image file to use in QEMU. The image file is setup as
>> a USB flash drive. The user can do the equivalent of removing the
>> flash drive by selecting the file in the "Eject Image File" submenu.
>> 
>> Signed-off-by: John Arbuckle 
> 
> I've thought a bit about this, and I really don't think this sort
> of feature should be part of QEMU itself. Our general design for
> how QEMU does this sort of thing is that an external program
> (virt-manager, for instance) is responsible for providing most
> of the UI conveniences the user wants, and QEMU's "ui" code is
> a fairly simple minimum-functionality affair. I agree with Markus
> that this separation of concerns has generally worked OK for us.
> 
> I don't think OSX should be an exception to this design model:
> (a) being an odd special case is never a good idea
> (b) as a practical matter, I'm the only person who really reviews
> OSX patches, and I don't have either the time nor the UI or OSX
> expertise to deal with maintaining what will effectively be a
> vm-manager grafted onto the side of QEMU
> 
> So I think your efforts would be better spent in either porting
> one of the Linux frontends like libvirt/virt-manager, or in
> writing a custom OSX specific frontend.

Given the overwhelming odds of this patch being committed, I have
decided to give up on it. 

I guess it is time for plan B - make the SD card reader actually work. 
Would you know what operating systems or targets can actually use
the SD card reader device in QEMU?

Re: [Qemu-devel] [PATCH v2] ui/cocoa.m: remove open dialog code

[Programmingkid]

On Sep 25, 2015, at 12:09 PM, Peter Maydell wrote:

> On 23 September 2015 at 16:06, Programmingkid  
> wrote:
>> Removes the open dialog code that runs when no arguments
>> are supplied with QEMU. Not everyone needs a hard drive
>> or cdrom to boot their target. A user might only need to
>> use their target's bios to do work. With that said,
>> this patch removes the unneeded open dialog code.
>> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> Add a dialog box that tells the user to start QEMU from
>> the commandline instead of the Finder.
>> 
>> ui/cocoa.m |   66
>> ---
>> 1 files changed, 14 insertions(+), 52 deletions(-)
>> 
>> diff --git a/ui/cocoa.m b/ui/cocoa.m
>> index 334e6f6..dc8e0f6 100644
>> --- a/ui/cocoa.m
>> +++ b/ui/cocoa.m
>> @@ -814,7 +814,6 @@ QemuCocoaView *cocoaView;
>> {
>> }
>> - (void)startEmulationWithArgc:(int)argc argv:(char**)argv;
>> -- (void)openPanelDidEnd:(NSOpenPanel *)sheet
>> returnCode:(NSInteger)returnCode contextInfo:(void *)contextInfo;
>> - (void)doToggleFullScreen:(id)sender;
>> - (void)toggleFullScreen:(id)sender;
>> - (void)showQEMUDoc:(id)sender;
>> @@ -896,27 +895,20 @@ QemuCocoaView *cocoaView;
>> {
>> COCOA_DEBUG("QemuCocoaAppController: applicationDidFinishLaunching\n");
>> 
>> 
>> 
>> -// Display an open dialog box if no arguments were passed or
>> -// if qemu was launched from the finder ( the Finder passes "-psn" )
>> -if( gArgc <= 1 || strncmp ((char *)gArgv[1], "-psn", 4) == 0) {
> 
> Here we look at whether we were passed "-psn" as our check for
> whether we were launched from the Finder...
> 
>> +// if the user launched QEMU from the Finder
>> +if(gArgc == 1) {
> 
> ...but here you have changed the condition. Why?
I will change it back to checking for -psn.

> (Also, isn't a simple test on gArgc going to cause us to put up
> the dialog box even if qemu was started from the command line with
> no arguments?)

I suppose you are right. Will make a new patch to fix this problem.

Re: [Qemu-devel] [PATCH v3] ui/cocoa.m: Add Mount image file menu item

[Programmingkid]

On Sep 24, 2015, at 2:57 AM, Markus Armbruster wrote:

> Programmingkid  writes:
> 
>> On Sep 23, 2015, at 4:35 PM, Peter Maydell wrote:
>> 
>>> On 17 September 2015 at 21:17, Programmingkid
>>>  wrote:
>>>> Add "Mount Image File..." and a "Eject Image File" menu items to
>>>> cocoa interface. This patch makes sharing files between the
>>>> host and the guest user-friendly.
>>>> 
>>>> The "Mount Image File..." menu item displays a dialog box having the
>>>> user pick an image file to use in QEMU. The image file is setup as
>>>> a USB flash drive. The user can do the equivalent of removing the
>>>> flash drive by selecting the file in the "Eject Image File" submenu.
>>>> 
>>>> Signed-off-by: John Arbuckle 
>>> 
>>> I've thought a bit about this, and I really don't think this sort
>>> of feature should be part of QEMU itself. Our general design for
>>> how QEMU does this sort of thing is that an external program
>>> (virt-manager, for instance) is responsible for providing most
>>> of the UI conveniences the user wants, and QEMU's "ui" code is
>>> a fairly simple minimum-functionality affair. I agree with Markus
>>> that this separation of concerns has generally worked OK for us.
>>> 
>>> I don't think OSX should be an exception to this design model:
>>> (a) being an odd special case is never a good idea
>>> (b) as a practical matter, I'm the only person who really reviews
>>> OSX patches, and I don't have either the time nor the UI or OSX
>>> expertise to deal with maintaining what will effectively be a
>>> vm-manager grafted onto the side of QEMU
>>> 
>>> So I think your efforts would be better spent in either porting
>>> one of the Linux frontends like libvirt/virt-manager, or in
>>> writing a custom OSX specific frontend.
>> 
>> I understand that time is precious. It is one of those things
>> that we only have a finite amount of. Every user can agree
>> to that. This patch was pretty hairy looking with the QDict
>> and other unfamiliar code. With that said I'm not ready to
>> give up on this patch. It is a huge time saver for the user.
>> Without it, the user would need to spend a lot of time
>> investigating documentation. What's worse is the user
>> would have to type out full paths to files they need. This
>> would definitely be error prone and frustrating.
> 
> Nobody is challenging the idea that many users appreciate a GUI.
> 
> What we've been trying to tell you is where in this software layer cake
> the GUI should be.  In Peter's words, "our general design for how QEMU
> does this sort of thing is that an external program (virt-manager, for
> instance) is responsible for providing most of the UI conveniences".

That is easy for you to say. Linux already has virt-manager. Mac OS X doesn't. 
Expecting someone to just go and port another program to Mac OS X is 
unreasonable. The amount of time and energy it would take to do so
would make it hard. 

> 
>> This patch can definitely be more simplified. QMP
>> commands could be used in place of C functions. 
>> This would reduce the patch size greatly. 
> 
> You're quite welcome to use QMP the way it wants to be used: as an
> external interface.
> 
> Abusing it as internal interface won't fly.

The QMP interface is primarily there to help a gui interact with QEMU. That
is what I intend to use it for.

[Qemu-devel] [PATCH v3] ui/cocoa.m: prevent stuck key situation

[Programmingkid]

When the user puts QEMU in the background while holding
down a key, QEMU will not receive the keyup event when
the user lets go of the key. When the user goes back to
QEMU, QEMU will think the key is still down causing
stuck key symptoms. This patch fixes this problem by
releasing all down keys when QEMU goes into the
background. 

Signed-off-by: John Arbuckle 

---
Changed value of max_index variable.
Added more to raiseAllKeys method's comment.

 ui/cocoa.m |   26 ++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..ee88a9e 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -304,6 +304,7 @@ static void handleAnyDeviceErrors(Error * err)
 - (float) cdx;
 - (float) cdy;
 - (QEMUScreen) gscreen;
+- (void) raiseAllKeys;
 @end
 
 QemuCocoaView *cocoaView;
@@ -798,6 +799,24 @@ QemuCocoaView *cocoaView;
 - (float) cdx {return cdx;}
 - (float) cdy {return cdy;}
 - (QEMUScreen) gscreen {return screen;}
+
+/*
+ * Makes the target think all down keys are being released.
+ * This prevents a stuck key problem, since we will not see
+ * key up events for those keys after we have lost focus.
+ */
+- (void) raiseAllKeys
+{
+int index;
+const int max_index = ARRAY_SIZE(modifiers_state);
+
+   for (index = 0; index < max_index; index++) {
+   if (modifiers_state[index]) {
+   modifiers_state[index] = 0;
+   qemu_input_event_send_key_number(dcl->con, index, false);
+   }
+   }
+}
 @end
 
 
@@ -933,6 +952,13 @@ QemuCocoaView *cocoaView;
 return YES;
 }
 
+/* Called when QEMU goes into the background */
+- (void) applicationWillResignActive: (NSNotification *)aNotification
+{
+COCOA_DEBUG("QemuCocoaAppController: applicationWillResignActive\n");
+[cocoaView raiseAllKeys];
+}
+
 - (void)startEmulationWithArgc:(int)argc argv:(char**)argv
 {
 COCOA_DEBUG("QemuCocoaAppController: startEmulationWithArgc\n");
-- 
1.7.5.4

[Qemu-devel] [PATCH v3] ui/cocoa.m: verify with user before quitting QEMU

[Programmingkid]

This patch prevents the user from accidentally quitting QEMU by pushing 
Command-Q or by pushing the close button on the main window. When
the user does one of these two things, a dialog box appears verifying
with the user if he or she wants to quit QEMU.

Signed-off-by: John Arbuckle 

---
Replaced NSRunAlertPanel() with NSAlert.
Added more informative comment to windowShouldClose: method.

 ui/cocoa.m |   39 ++-
 1 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..a46014c 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -809,7 +809,7 @@ QemuCocoaView *cocoaView;
 */
 @interface QemuCocoaAppController : NSObject
 #if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6)
- 
+   
 #endif
 {
 }
@@ -829,6 +829,7 @@ QemuCocoaView *cocoaView;
 - (void)powerDownQEMU:(id)sender;
 - (void)ejectDeviceMedia:(id)sender;
 - (void)changeDeviceMedia:(id)sender;
+- (BOOL)verifyQuit;
 @end
 
 @implementation QemuCocoaAppController
@@ -862,6 +863,7 @@ QemuCocoaView *cocoaView;
 #endif
 [normalWindow makeKeyAndOrderFront:self];
 [normalWindow center];
+[normalWindow setDelegate: self];
 stretch_video = false;
 
 /* Used for displaying pause on the screen */
@@ -933,6 +935,26 @@ QemuCocoaView *cocoaView;
 return YES;
 }
 
+- (NSApplicationTerminateReply)applicationShouldTerminate:
+ (NSApplication 
*)sender
+{
+COCOA_DEBUG("QemuCocoaAppController: applicationShouldTerminate\n");
+return [self verifyQuit];
+}
+
+/* Called when the user clicks on a window's close button */
+- (BOOL)windowShouldClose:(id)sender
+{
+COCOA_DEBUG("QemuCocoaAppController: windowShouldClose\n");
+[NSApp terminate: sender];
+/* If the user allows the application to quit then the call to
+ * NSApp terminate will never return. If we get here then the user
+ * cancelled the quit, so we should return NO to not permit the
+ * closing of this window.
+ */
+return NO;
+}
+
 - (void)startEmulationWithArgc:(int)argc argv:(char**)argv
 {
 COCOA_DEBUG("QemuCocoaAppController: startEmulationWithArgc\n");
@@ -1125,6 +1147,21 @@ QemuCocoaView *cocoaView;
 }
 }
 
+/* Verifies if the user really wants to quit */
+- (BOOL)verifyQuit
+{
+NSAlert *alert = [NSAlert new];
+[alert autorelease];
+[alert setMessageText: @"Are you sure you want to quit QEMU?"];
+[alert addButtonWithTitle: @"Cancel"];
+[alert addButtonWithTitle: @"Quit"];
+if([alert runModal] == NSAlertSecondButtonReturn) {
+return YES;
+} else {
+return NO;
+}
+}
+
 @end
 
 
-- 
1.7.5.4

Re: [Qemu-devel] [PATCH v2] ui/cocoa.m: prevent stuck key situation

[Programmingkid]

On Sep 23, 2015, at 8:34 PM, Peter Maydell wrote:

> On 23 September 2015 at 17:17, Programmingkid  
> wrote:
>> When the user puts QEMU in the background while holding
>> down a key, QEMU will not receive the keyup event when
>> the user lets go of the key. When the user goes back to
>> QEMU, QEMU will think the key is still down causing
>> stuck key symptoms. This patch fixes this problem by
>> releasing all down keys when QEMU goes into the
>> background.
>> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> Removed the modifiers_state global variable.
>> Added a raiseAllKeys method.
>> 
>> ui/cocoa.m |   26 ++
>> 1 files changed, 26 insertions(+), 0 deletions(-)
>> 
>> diff --git a/ui/cocoa.m b/ui/cocoa.m
>> index 334e6f6..4d15553 100644
>> --- a/ui/cocoa.m
>> +++ b/ui/cocoa.m
>> @@ -304,6 +304,7 @@ static void handleAnyDeviceErrors(Error * err)
>> - (float) cdx;
>> - (float) cdy;
>> - (QEMUScreen) gscreen;
>> +- (void) raiseAllKeys;
>> @end
>> 
>> QemuCocoaView *cocoaView;
>> @@ -798,6 +799,23 @@ QemuCocoaView *cocoaView;
>> - (float) cdx {return cdx;}
>> - (float) cdy {return cdy;}
>> - (QEMUScreen) gscreen {return screen;}
>> +
>> +/*
>> + * Makes the target think all down keys are being released.
>> + * This prevents a stuck key problem.
> 
> ", since we will not see key up events for those keys after we
> have lost focus."

If that is all the changes that are required, I wouldn't mind if you just
added it to the patch.

> 
>> + */
>> +- (void) raiseAllKeys
>> +{
>> +int index;
>> +const int max_index = 220; /* This is the highest value key */
> 
> No, you need to use ARRAY_SIZE.

I did use it, it didn't work. The command key would still stay down.
This is because the command key has a value of 220. The keymap
array size is only 126. I know it is confusing. I was thinking of using
cocoa_keycode_to_qemu() to translate the index to the qemu (pc xt)
values, but that would be expensive in terms of cpu usage. 

> 
>> +
>> +   for (index = 0; index <= max_index; index++) {
>> +   if (modifiers_state[index]) {
>> +   modifiers_state[index] = 0;
>> +   qemu_input_event_send_key_number(dcl->con, index, false);
>> +   }
>> +   }
> 
> -- PMM

[Qemu-devel] [PATCH v2] ui/cocoa.m: prevent stuck key situation

[Programmingkid]

When the user puts QEMU in the background while holding
down a key, QEMU will not receive the keyup event when
the user lets go of the key. When the user goes back to
QEMU, QEMU will think the key is still down causing
stuck key symptoms. This patch fixes this problem by
releasing all down keys when QEMU goes into the
background. 

Signed-off-by: John Arbuckle 

---
Removed the modifiers_state global variable.
Added a raiseAllKeys method.

 ui/cocoa.m |   26 ++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..4d15553 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -304,6 +304,7 @@ static void handleAnyDeviceErrors(Error * err)
 - (float) cdx;
 - (float) cdy;
 - (QEMUScreen) gscreen;
+- (void) raiseAllKeys;
 @end
 
 QemuCocoaView *cocoaView;
@@ -798,6 +799,23 @@ QemuCocoaView *cocoaView;
 - (float) cdx {return cdx;}
 - (float) cdy {return cdy;}
 - (QEMUScreen) gscreen {return screen;}
+
+/*
+ * Makes the target think all down keys are being released.
+ * This prevents a stuck key problem.
+ */
+- (void) raiseAllKeys
+{
+int index;
+const int max_index = 220; /* This is the highest value key */
+
+   for (index = 0; index <= max_index; index++) {
+   if (modifiers_state[index]) {
+   modifiers_state[index] = 0;
+   qemu_input_event_send_key_number(dcl->con, index, false);
+   }
+   }
+}
 @end
 
 
@@ -933,6 +951,14 @@ QemuCocoaView *cocoaView;
 return YES;
 }
 
+/* Called when QEMU goes into the background */
+- (void) applicationWillResignActive: (NSNotification *)aNotification
+{
+COCOA_DEBUG("QemuCocoaAppController: applicationWillResignActive\n");
+
+[cocoaView raiseAllKeys];
+}
+
 - (void)startEmulationWithArgc:(int)argc argv:(char**)argv
 {
 COCOA_DEBUG("QemuCocoaAppController: startEmulationWithArgc\n");
-- 
1.7.5.4

[Qemu-devel] [PATCH v2] ui/cocoa.m: remove open dialog code

[Programmingkid]

Removes the open dialog code that runs when no arguments
are supplied with QEMU. Not everyone needs a hard drive
or cdrom to boot their target. A user might only need to
use their target's bios to do work. With that said,
this patch removes the unneeded open dialog code. 

Signed-off-by: John Arbuckle 

---
Add a dialog box that tells the user to start QEMU from
the commandline instead of the Finder.

 ui/cocoa.m |   66 ---
 1 files changed, 14 insertions(+), 52 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..dc8e0f6 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -814,7 +814,6 @@ QemuCocoaView *cocoaView;
 {
 }
 - (void)startEmulationWithArgc:(int)argc argv:(char**)argv;
-- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode 
contextInfo:(void *)contextInfo;
 - (void)doToggleFullScreen:(id)sender;
 - (void)toggleFullScreen:(id)sender;
 - (void)showQEMUDoc:(id)sender;
@@ -896,27 +895,20 @@ QemuCocoaView *cocoaView;
 {
 COCOA_DEBUG("QemuCocoaAppController: applicationDidFinishLaunching\n");
 
-// Display an open dialog box if no arguments were passed or
-// if qemu was launched from the finder ( the Finder passes "-psn" )
-if( gArgc <= 1 || strncmp ((char *)gArgv[1], "-psn", 4) == 0) {
-NSOpenPanel *op = [[NSOpenPanel alloc] init];
-[op setPrompt:@"Boot image"];
-[op setMessage:@"Select the disk image you want to boot.\n\nHit the 
\"Cancel\" button to quit"];
-#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6)
-[op setAllowedFileTypes:supportedImageFileTypes];
-[op beginSheetModalForWindow:normalWindow
-completionHandler:^(NSInteger returnCode)
-{ [self openPanelDidEnd:op
-  returnCode:returnCode contextInfo:NULL ]; } ];
-#else
-// Compatibility code for pre-10.6, using deprecated method
-[op beginSheetForDirectory:nil file:nil types:filetypes
-  modalForWindow:normalWindow modalDelegate:self
-  
didEndSelector:@selector(openPanelDidEnd:returnCode:contextInfo:) 
contextInfo:NULL];
-#endif
-} else {
-// or launch QEMU, with the global args
-[self startEmulationWithArgc:gArgc argv:(char **)gArgv];
+// if the user launched QEMU from the Finder
+if(gArgc == 1) {
+NSAlert *alert = [NSAlert new];
+[alert autorelease];
+[alert setMessageText: @"Please start QEMU from the command line with"
+  " appropriate 
arguments"];
+[alert addButtonWithTitle: @"Quit"];
+[alert addButtonWithTitle: @"Continue"];
+if([alert runModal] == NSAlertFirstButtonReturn) {
+[NSApp terminate: self];
+} else {
+// launch QEMU, with the global args
+[self startEmulationWithArgc:gArgc argv:(char **)gArgv];
+}
 }
 }
 
@@ -942,36 +934,6 @@ QemuCocoaView *cocoaView;
 exit(status);
 }
 
-- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode 
contextInfo:(void *)contextInfo
-{
-COCOA_DEBUG("QemuCocoaAppController: openPanelDidEnd\n");
-
-/* The NSFileHandlingPanelOKButton/NSFileHandlingPanelCancelButton values 
for
- * returnCode strictly only apply for the 10.6-and-up 
beginSheetModalForWindow
- * API. For the legacy pre-10.6 beginSheetForDirectory API they are 
NSOKButton
- * and NSCancelButton. However conveniently the values are the same.
- * We use the non-legacy names because the others are deprecated in OSX 
10.10.
- */
-if (returnCode == NSFileHandlingPanelCancelButton) {
-exit(0);
-} else if (returnCode == NSFileHandlingPanelOKButton) {
-char *img = (char*)[ [ [ sheet URL ] path ] 
cStringUsingEncoding:NSASCIIStringEncoding];
-
-char **argv = g_new(char *, 4);
-
-[sheet close];
-
-argv[0] = g_strdup(gArgv[0]);
-argv[1] = g_strdup("-hda");
-argv[2] = g_strdup(img);
-argv[3] = NULL;
-
-// printf("Using argc %d argv %s -hda %s\n", 3, gArgv[0], img);
-
-[self startEmulationWithArgc:3 argv:(char**)argv];
-}
-}
-
 /* We abstract the method called by the Enter Fullscreen menu item
  * because Mac OS 10.7 and higher disables it. This is because of the
  * menu item's old selector's name toggleFullScreen:
-- 
1.7.5.4

Re: [Qemu-devel] [PATCH v3] ui/cocoa.m: Add Mount image file menu item

[Programmingkid]

On Sep 23, 2015, at 4:35 PM, Peter Maydell wrote:

> On 17 September 2015 at 21:17, Programmingkid  
> wrote:
>> Add "Mount Image File..." and a "Eject Image File" menu items to
>> cocoa interface. This patch makes sharing files between the
>> host and the guest user-friendly.
>> 
>> The "Mount Image File..." menu item displays a dialog box having the
>> user pick an image file to use in QEMU. The image file is setup as
>> a USB flash drive. The user can do the equivalent of removing the
>> flash drive by selecting the file in the "Eject Image File" submenu.
>> 
>> Signed-off-by: John Arbuckle 
> 
> I've thought a bit about this, and I really don't think this sort
> of feature should be part of QEMU itself. Our general design for
> how QEMU does this sort of thing is that an external program
> (virt-manager, for instance) is responsible for providing most
> of the UI conveniences the user wants, and QEMU's "ui" code is
> a fairly simple minimum-functionality affair. I agree with Markus
> that this separation of concerns has generally worked OK for us.
> 
> I don't think OSX should be an exception to this design model:
> (a) being an odd special case is never a good idea
> (b) as a practical matter, I'm the only person who really reviews
> OSX patches, and I don't have either the time nor the UI or OSX
> expertise to deal with maintaining what will effectively be a
> vm-manager grafted onto the side of QEMU
> 
> So I think your efforts would be better spent in either porting
> one of the Linux frontends like libvirt/virt-manager, or in
> writing a custom OSX specific frontend.

I understand that time is precious. It is one of those things
that we only have a finite amount of. Every user can agree
to that. This patch was pretty hairy looking with the QDict
and other unfamiliar code. With that said I'm not ready to
give up on this patch. It is a huge time saver for the user.
Without it, the user would need to spend a lot of time
investigating documentation. What's worse is the user
would have to type out full paths to files they need. This
would definitely be error prone and frustrating.

This patch can definitely be more simplified. QMP
commands could be used in place of C functions. 
This would reduce the patch size greatly. 

Re: [Qemu-devel] [PATCH] ui/cocoa.m: remove open dialog code

[Programmingkid]

On Sep 23, 2015, at 5:45 PM, Peter Maydell wrote:

> On 23 September 2015 at 14:38, Programmingkid  
> wrote:
>> 
>> On Sep 23, 2015, at 2:58 PM, Peter Maydell wrote:
>> 
>>> On 10 September 2015 at 17:49, Programmingkid  
>>> wrote:
>>>> Remove the open dialog code that runs when no arguments are supplied with
>>>> QEMU.
>>>> Not everyone needs a hard drive or cdrom to boot their target. A user might
>>>> only
>>>> need to use their target's bios to do work. With that said, this patch
>>>> removes
>>>> the unneeded open dialog code.
>>>> 
>>>> Signed-off-by: John Arbuckle 
>>> 
>>> OK, I think I agree we should drop this dialog box. For the benefit
>>> of people who try to start QEMU from the Finder, could you make it
>>> do "if we have one argument and it is '-psn' then bring up a dialog
>>> box saying "Please start QEMU from the command line with appropriate
>>> arguments" ?
>> 
>> We could do this. I'm thinking a dialog box with a continue and a
>> quit button. That ok?
> 
> Do we have any machines where continuing to run with no arguments is actually
> useful?

qemu-system-ppc does have openbios. This firmware does
have a whole environment that the user could work on. I 
use to study the forth language using it. 

Re: [Qemu-devel] [PATCH] ui/cocoa.m: prevent stuck key situation

[Programmingkid]

On Sep 23, 2015, at 2:04 PM, Peter Maydell wrote:

> On 18 September 2015 at 14:46, Programmingkid  
> wrote:
>> When the user puts QEMU in the background while holding down a key, QEMU
>> will
>> not receive the keyup event when the user lets go of the key. When the user
>> goes
>> back to QEMU, QEMU will think the key is still down causing stuck key
>> symptoms.
>> This patch fixes this problem by releasing all keys when QEMU goes into the
>> background.
> 
> Looks like maybe you're not wrapping lines early enough in your
> commit messages, resulting in this ugly effect when they're
> quoted. It's best to not have lines longer than 75 chars or so.

Sorry, will make the lines shorter in the future.

> 
>> Signed-off-by: John Arbuckle 
>> 
>> ---
>> ui/cocoa.m |   17 -
>> 1 files changed, 16 insertions(+), 1 deletions(-)
>> 
>> diff --git a/ui/cocoa.m b/ui/cocoa.m
>> index 334e6f6..d07b22d 100644
>> --- a/ui/cocoa.m
>> +++ b/ui/cocoa.m
>> @@ -69,6 +69,7 @@ char **gArgv;
>> bool stretch_video;
>> NSTextField *pauseLabel;
>> NSArray * supportedImageFileTypes;
>> +int modifiers_state[256];
> 
> Rather than making this global, could we have the applicationWillResignActive
> method call a new raiseAllKeys method on the NSView?

We could do that, but isn't this more of an app controller function?

>> 
>> 
>> 
>> // keymap conversion
>> int keymap[] =
>> @@ -274,7 +275,6 @@ static void handleAnyDeviceErrors(Error * err)
>> NSWindow *fullScreenWindow;
>> float cx,cy,cw,ch,cdx,cdy;
>> CGDataProviderRef dataProviderRef;
>> -int modifiers_state[256];
>> BOOL isMouseGrabbed;
>> BOOL isFullscreen;
>> BOOL isAbsoluteEnabled;
>> @@ -933,6 +933,21 @@ QemuCocoaView *cocoaView;
>> return YES;
>> }
>> 
>> 
>> 
>> +/* Called when QEMU goes into the background */
>> +- (void) applicationWillResignActive: (NSNotification *)aNotification
>> +{
>> +COCOA_DEBUG("QemuCocoaAppController: applicationWillResignActive\n");
>> +int keycode, index;
>> +const int max_index = 126; /* This is the size of the keymap array */
> 
> Hardcoding array sizes is never a good idea. We have an ARRAY_SIZE
> macro which automatically gets it right.

Didn't know about this macro. Will use it in the next patch.

> 
> 
>> +
>> +/* Release all the keys to prevent a stuck key situation */
>> +for(index = 0; index <= max_index; index++) {
>> +keycode = keymap[index];
>> +modifiers_state[keycode] = 0;
>> +qemu_input_event_send_key_number(dcl->con, keycode, false);
>> +}
> 
> This will send key-up events even for keys which are already up.
> Instead you can just send events for only the keys which are down
> (and avoid the lookup in keymap[] too):
> 
> 
>for (i = 0; i < ARRAY_SIZE(modifiers_state); i++) {
>if (modifiers_state[i])) {
>modifiers_state[i] = 0;
>qemu_input_event_send_key_number(dcl->con, i, false);
>}
>}

Sounds good. Will use it.

Re: [Qemu-devel] [PATCH] ui/cocoa.m: remove open dialog code

[Programmingkid]

On Sep 23, 2015, at 2:58 PM, Peter Maydell wrote:

> On 10 September 2015 at 17:49, Programmingkid  
> wrote:
>> Remove the open dialog code that runs when no arguments are supplied with
>> QEMU.
>> Not everyone needs a hard drive or cdrom to boot their target. A user might
>> only
>> need to use their target's bios to do work. With that said, this patch
>> removes
>> the unneeded open dialog code.
>> 
>> Signed-off-by: John Arbuckle 
> 
> OK, I think I agree we should drop this dialog box. For the benefit
> of people who try to start QEMU from the Finder, could you make it
> do "if we have one argument and it is '-psn' then bring up a dialog
> box saying "Please start QEMU from the command line with appropriate
> arguments" ?

We could do this. I'm thinking a dialog box with a continue and a quit button. 
That ok?

[Qemu-devel] [PATCH] hw/usb/dev-audio.c: make USB audio card sound perfect

[Programmingkid]

The USB audio card would not play audio well because its buffer was too small. 
Increasing it made it play perfectly. All the crackling and dropouts are gone.  

Signed-off-by: John Arbuckle 

---
This patch was tested on qemu-system-ppc running Linux and qemu-system-i386
running Windows XP. Windows XP sound output thru the USB audio card sounded
perfect. Linux did improve in sound quality, but it still wasn't perfect. I
think there are problems with the hcd-ohci.c file. The Mac OS 10.2 guest in 
qemu-system-ppc did not play sound due to USB issues unrelated to this patch. 

 hw/usb/dev-audio.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c
index f092bb8..e4e4989 100644
--- a/hw/usb/dev-audio.c
+++ b/hw/usb/dev-audio.c
@@ -88,6 +88,7 @@ static const USBDescStrings usb_audio_stringtable = {
 #define USBAUDIO_PACKET_SIZE 192
 #define USBAUDIO_SAMPLE_RATE 48000
 #define USBAUDIO_PACKET_INTERVAL 1
+#define BUFFER_MULTIPLIER32
 
 static const USBDescIface desc_iface[] = {
 {
@@ -664,7 +665,7 @@ static const VMStateDescription vmstate_usb_audio = {
 static Property usb_audio_properties[] = {
 DEFINE_PROP_UINT32("debug", USBAudioState, debug, 0),
 DEFINE_PROP_UINT32("buffer", USBAudioState, buffer,
-   8 * USBAUDIO_PACKET_SIZE),
+   BUFFER_MULTIPLIER * USBAUDIO_PACKET_SIZE),
 DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
1.7.5.4

Re: [Qemu-devel] [PATCH] ui/cocoa.m: remove open dialog code

[Programmingkid]

On Sep 21, 2015, at 3:01 PM, Peter Maydell wrote:

> On 19 September 2015 at 08:01, Programmingkid  
> wrote:
>> 
>> On Sep 19, 2015, at 10:58 AM, Peter Maydell wrote:
>>> By the way, I don't mean that I'm completely opposed to the
>>> idea of dropping the open-dialog. I'd just like to hear
>>> some input from other people who care about OSX QEMU
>>> rather than just you and me.
>> 
>> Who else is there?
> 
> Andreas had some feedback on IRC.
> 
> I've thought about this a bit and:
> 
> (1) this "open-dialog if no command line arguments" is really QEMU
> trying to provide features that ought to be in a virt-manager
> type wrapper, not in QEMU proper. So that's one argument for
> dropping it. A proper wrapper VM manager program would obviously
> launch its VM management GUI window if started via the GUI (or
> would have VM config files that it would associate to itself and
> run if the files were clicked).
> 
> (2) Dropping the dialog box brings the OSX UI code closer into
> line with the other UI frontends. That means that at some point
> in the future we could maybe restructure it so it doesn't have
> the weird "UI's main function takes control at startup" structure,
> and we can just init the UI in the same way the other UIs do.
> 
> (3) if we don't drop it, we should probably only have it when
> we don't see the magic argument that means "we got invoked by
> somebody double-clicking the app in Finder".
> 
> Currently I'm leaning towards "yes, just drop the dialog box
> completely".

Great to hear.

[Qemu-devel] [PATCH v2] ui/cocoa.m: verify with user before quitting QEMU

[Programmingkid]

This patch prevents the user from accidentally quitting QEMU by pushing 
Command-Q or by pushing the close button on the main window. When the user does
one of these two things, a dialog box appears verifying with the user if he or
she wants to quit QEMU.

Signed-off-by: John Arbuckle 

---
 ui/cocoa.m |   35 +--
 1 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 334e6f6..3c5172c 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -807,10 +807,11 @@ QemuCocoaView *cocoaView;
 QemuCocoaAppController
  --
 */
-@interface QemuCocoaAppController : NSObject
+@interface QemuCocoaAppController : NSObject = MAC_OS_X_VERSION_10_6)
- 
+ , NSApplicationDelegate
 #endif
+>
 {
 }
 - (void)startEmulationWithArgc:(int)argc argv:(char**)argv;
@@ -829,6 +830,7 @@ QemuCocoaView *cocoaView;
 - (void)powerDownQEMU:(id)sender;
 - (void)ejectDeviceMedia:(id)sender;
 - (void)changeDeviceMedia:(id)sender;
+- (BOOL)verifyQuit;
 @end
 
 @implementation QemuCocoaAppController
@@ -862,6 +864,7 @@ QemuCocoaView *cocoaView;
 #endif
 [normalWindow makeKeyAndOrderFront:self];
 [normalWindow center];
+[normalWindow setDelegate: self];
 stretch_video = false;
 
 /* Used for displaying pause on the screen */
@@ -933,6 +936,21 @@ QemuCocoaView *cocoaView;
 return YES;
 }
 
+- (NSApplicationTerminateReply)applicationShouldTerminate:
+ (NSApplication 
*)sender
+{
+COCOA_DEBUG("QemuCocoaAppController: applicationShouldTerminate\n");
+return [self verifyQuit];
+}
+
+/* Called when the user clicks on a window's close button */
+- (BOOL)windowShouldClose:(id)sender
+{
+COCOA_DEBUG("QemuCocoaAppController: windowShouldClose\n");
+[NSApp terminate: sender];
+return NO; /* The main window should always be available */
+}
+
 - (void)startEmulationWithArgc:(int)argc argv:(char**)argv
 {
 COCOA_DEBUG("QemuCocoaAppController: startEmulationWithArgc\n");
@@ -1125,6 +1143,19 @@ QemuCocoaView *cocoaView;
 }
 }
 
+/* Verifies if the user really wants to quit */
+- (BOOL)verifyQuit
+{
+NSInteger response;
+response = NSRunAlertPanel(@"Quit?", @"Are you sure you want to quit?",
+   @"Cancel", @"Quit", 
nil);
+if(response == NSAlertAlternateReturn) {
+return YES; /* Yes, I want to quit */
+} else {
+return NO; /* No, I don't want to quit */
+}
+}
+
 @end
 
 
-- 
1.7.5.4