From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46052 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmALk-0007Ew-0t for qemu-devel@nongnu.org; Thu, 19 Aug 2010 15:00:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmALi-0008Ha-94 for qemu-devel@nongnu.org; Thu, 19 Aug 2010 15:00:27 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:53168) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmALi-0008HN-5U for qemu-devel@nongnu.org; Thu, 19 Aug 2010 15:00:26 -0400 Received: by yxn35 with SMTP id 35so943426yxn.4 for ; Thu, 19 Aug 2010 12:00:25 -0700 (PDT) Message-ID: <4C6D7F46.4090405@codemonkey.ws> Date: Thu, 19 Aug 2010 14:00:22 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 8/9] spice: simple display References: <1282221625-29501-1-git-send-email-kraxel@redhat.com> <1282221625-29501-9-git-send-email-kraxel@redhat.com> <4C6D4221.8080504@codemonkey.ws> <4C6D5641.8080004@redhat.com> In-Reply-To: <4C6D5641.8080004@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org On 08/19/2010 11:05 AM, Gerd Hoffmann wrote: >> While not really unsafe, the qemu_malloc functions are not guaranteed to >> be re-entrant by the interfaces today. It's also terribly subtle to have >> to rely on implicit re-entrance safety. > > The underlying malloc() is re-entrant, isn't it? > pflib (which is called too) is re-entrant too. > Otherwise only private data is accessed (under lock when needed). Yes, I looked too and agree that it's safe now. But we're sloppy as hell in qemu about depending on global state and I can imagine someone adding something to these functions that would create an issue. I think documentation would be sufficient, at least for now. >> Having spice as an independent interface to the current display_type >> switching seems awkward to me. > > Having remote desktop protocols as DT_something seems awkward to me. > It makes sense for the local display (being none, curses, sdl, fbdev, > whatever). For remote display protocols I see no reason why we > shouldn't have multiple of them enabled at the same time, so the user > can connect with whatever he wants. And that even in parallel to a > local display if needed. > > The state the patch introduces is a bit inconsistent though. But I'd > rather drop DT_VNC instead of adding DT_SPICE. Yes, I would think that would be reasonable. Regards, Anthony Liguori > cheers, > Gerd >