From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beh0o-0006Lu-88 for qemu-devel@nongnu.org; Tue, 30 Aug 2016 07:15:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beh0m-00020k-87 for qemu-devel@nongnu.org; Tue, 30 Aug 2016 07:15:25 -0400 Date: Tue, 30 Aug 2016 14:15:14 +0300 From: "Michael S. Tsirkin" Message-ID: <20160830141341-mutt-send-email-mst@kernel.org> References: <1472526419-5900-1-git-send-email-jasowang@redhat.com> <1472526419-5900-3-git-send-email-jasowang@redhat.com> <20160830093127.49463d9d.cornelia.huck@de.ibm.com> <20160830130128-mutt-send-email-mst@kernel.org> <20160830130926-mutt-send-email-mst@kernel.org> <20160830131105.74f78a45.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160830131105.74f78a45.cornelia.huck@de.ibm.com> Subject: Re: [Qemu-devel] qom and debug (was: [PATCH for 2.8 02/11] virtio: convert to use DMA api) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Jason Wang , qemu-devel@nongnu.org, pbonzini@redhat.com, peterx@redhat.com, wexu@redhat.com, vkaplans@redhat.com, Stefan Hajnoczi , Kevin Wolf , Amit Shah , qemu-block@nongnu.org On Tue, Aug 30, 2016 at 01:11:05PM +0200, Cornelia Huck wrote: > On Tue, 30 Aug 2016 13:21:23 +0300 > "Michael S. Tsirkin" wrote: > > > BTW downstreams are building with --disable-qom-cast-debug which drops > > all QOM casts on data path - one way is to say we just make this the > > default upstream as well. Another to say that we want to distinguish > > fast path calls from slow path, this way we will be able to bring back > > some of the checks. > > I find CONFIG_QOM_CAST_DEBUG a bit inconsistent, btw: > > - for object casts, we optimize away all checks and just return the > object for !debug > - for class casts, we optimize away only the caching and still keep the > checking (why would we drop the caching if this can speed up things?) > > We certainly want to have debug turned on during development to avoid > nasty surprises later (otherwise, why even bother?), but it makes sense > to turn it off for a release. (Is there an easy way to turn it off for > the release, normal or stable, and keep it during the development > cycle?) I think the assumption was class casts are not on data path. Ideally we'd keep it on for release too for non-datapath things, to help improve security. -- MST