From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a7XVh-0005zk-7k for qemu-devel@nongnu.org; Fri, 11 Dec 2015 18:54:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a7XVf-00073J-QB for qemu-devel@nongnu.org; Fri, 11 Dec 2015 18:54:01 -0500 References: <69D59CD8-84A3-4C9E-93F4-D366C412F4C6@gmail.com> <20151211220053.GA30085@localhost.localdomain> <29C0AA57-484E-4076-B6D5-005657067BF9@gmail.com> From: Eric Blake Message-ID: <566B620A.5010703@redhat.com> Date: Fri, 11 Dec 2015 16:53:46 -0700 MIME-Version: 1.0 In-Reply-To: <29C0AA57-484E-4076-B6D5-005657067BF9@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ELVOprNnjmsjwxMwK5bbmE4qdqbdQ5mcw" Subject: Re: [Qemu-devel] [Qemu-block] ping [PATCH v11] block/raw-posix.c: Make physical devices usable in QEMU under Mac OS X host List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid , Jeff Cody Cc: Kevin Wolf , qemu-devel qemu-devel , Qemu-block This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ELVOprNnjmsjwxMwK5bbmE4qdqbdQ5mcw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/11/2015 04:40 PM, Programmingkid wrote: > I guess the commit message is a little out of date. How about this: >=20 > 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. >=20 The use of "Also" in a commit message is often a sign of trying to do too much in one patch. If you are doing two distinct things (adding a new message, vs. adding the ability to use a DVD disk), then two patches is probably the best way to approach it. >> Also, this patch seems garbled. When saved via Mutt, or when I view >> it "raw", there are '=3D20" and '=3D3D' all around, a sure sign that i= t 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. >=20 > 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. Your mail was sent with: > Content-Type: text/plain; charset=3Dus-ascii > Content-Transfer-Encoding: quoted-printable > Mime-Version: 1.0 (Apple Message framework v1084) and the body indeed contains quoted-printable text, such as: > @@ -1975,32 +1976,46 @@ BlockDriver bdrv_file =3D3D { > /* host device */ > =3D20 Many mailers are good enough to re-render things on the fly (Thunderbird, for example, does not have those annoying =3D3D and =3D20 insertions in the displayed text) - but what gets rendered in the mail client is different than what the mail client saves to file. Mails sent by 'git send-email', on the other hand, use: > MIME-Version: 1.0 > Content-Type: text/plain; charset=3Dus-ascii > Content-Disposition: inline Apparently, mutt doesn't quite defang a quoted-printable message properly, and/or 'git am' doesn't take too well to a quoted-printable message when trying to apply a saved file as a patch. Which is all the more reason why using the same tool as everyone else makes sure that your patches will interoperate with the receivers' tools the same as the receiver is already used to handling other patches. >> Just use g_strdup(). >=20 > I like snprintf() because it very well documented. So is g_strdup(). But more important than being well-documented, g_strdup() also has the benefit of being correctly usable with less boilerplate - you can accomplish the same task in fewer lines of code, and focus the reviewer on your task rather than on the boilerplate. That, and I've seen a number of programs that incorrectly use snprintf() (such as incorrectly sizing a buffer, or failing to check for sizing errors after the fact). An interface that is hard to use correctly should be avoided in favor of one that is less mental effort. >=20 > Is this what you had in mind: >=20 > mediaType =3D g_strdup(matching_array[index]); Pretty much, coupled with g_free(mediaType) later on. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ELVOprNnjmsjwxMwK5bbmE4qdqbdQ5mcw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWa2IKAAoJEKeha0olJ0NqvbMH/AuAHE7N9Z55wcIIyyKrv/RU HTKMcKKysyAm0r1/mLN9C04r8q3yBREQXB/xNxIZoQULZNgzefYh2w+J3fMxi8Hd 8OiDAkT6G2h/nqJQD0HTJu1dK/xyEHBFdgjKAnJr6JfkIKgrpBlJE3Zg8m9/k4bl IeU9N0CD5ntxAdvtvWkmt3RqB1RMkwyHgTktWaG7BB/ttUc0/U/D/NeOH7GvEgaO MaQXJg9qX01KzL2pMe6/iLo6bATeneW/k3xYcYJTzJb77ISRoWxPzOHv75921J+X SgtyJg4IrLXF6BqzdRJrDrEFmBHb0WIGz8PfS8Nbt9fI6iZw9V/7iNvy5u+Ex34= =IShl -----END PGP SIGNATURE----- --ELVOprNnjmsjwxMwK5bbmE4qdqbdQ5mcw--