From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4bCD-00057q-JS for qemu-devel@nongnu.org; Mon, 15 Jun 2015 16:41:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4bCA-00026x-E1 for qemu-devel@nongnu.org; Mon, 15 Jun 2015 16:41:29 -0400 Received: from mail-yk0-f173.google.com ([209.85.160.173]:34149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4bCA-00026n-9W for qemu-devel@nongnu.org; Mon, 15 Jun 2015 16:41:26 -0400 Received: by ykfl8 with SMTP id l8so66563776ykf.1 for ; Mon, 15 Jun 2015 13:41:25 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20150615111833.0d5398fe@redhat.com> References: <1434205258-1932-1-git-send-email-armbru@redhat.com> <1434205258-1932-5-git-send-email-armbru@redhat.com> <20150615111833.0d5398fe@redhat.com> From: Peter Maydell Date: Mon, 15 Jun 2015 21:41:05 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 04/11] qerror: Eliminate QERR_DEVICE_NOT_FOUND List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Kevin Wolf , Michael Roth , Markus Armbruster , Stefan Hajnoczi , QEMU Developers On 15 June 2015 at 16:18, Luiz Capitulino wrote: > On Sat, 13 Jun 2015 16:20:51 +0200 > Markus Armbruster wrote: > >> Error classes other than ERROR_CLASS_GENERIC_ERROR should not be used >> in new code. Hiding them in QERR_ macros makes new uses hard to spot. >> Fortunately, there's just one such macro left. Eliminate it with this >> coccinelle semantic patch: >> >> @@ >> expression EP, E; >> @@ >> -error_set(EP, QERR_DEVICE_NOT_FOUND, E) >> +error_set(EP, ERROR_CLASS_DEVICE_NOT_FOUND, "Device '%s' not found", E) > > This is a bit minor, but I think I'd have created a new function instead, > say error_set_enodev(). This avoids all the duplication. But I'm not asking > you to change, as the patch is good and this can be done in the future if > we so want. The thing about that kind of generic set-an-error function is that it encourages people to use it rather than providing an error message that's more specific and helpful for the particular situation. That might not be a problem in this patch (I haven't read it), but I mention it because I have a patch onlist elsewhere which undoes a bit of "generic error based on an errno" in favour of being more specific about why something didn't work. thanks -- PMM