From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56306 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PLY9S-0002bN-EH for qemu-devel@nongnu.org; Thu, 25 Nov 2010 04:30:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PLY9R-0001US-5o for qemu-devel@nongnu.org; Thu, 25 Nov 2010 04:30:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PLY9Q-0001U7-R3 for qemu-devel@nongnu.org; Thu, 25 Nov 2010 04:30:01 -0500 Message-ID: <4CEE2CCA.6000002@redhat.com> Date: Thu, 25 Nov 2010 10:30:50 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/1] iscsi: add iSCSI block device support References: <20101124170437.GG31124@lst.de> <1290659543.2509.76.camel@haakon2.linux-iscsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ronnie sahlberg Cc: Stefan Hajnoczi , Hannes Reinecke , Christoph Hellwig , "Nicholas A. Bellinger" , qemu-devel@nongnu.org Am 25.11.2010 06:22, schrieb ronnie sahlberg: > Nicholas, > below. > > On Thu, Nov 25, 2010 at 3:32 PM, Nicholas A. Bellinger > wrote: > >> But existing code aside, I think having a small userspace iSCSI >> initiator built into QEMU that 'just works' across all host environments >> would be a pretty useful thing, even if the scalibility / scope is >> limited compared to existing kernel host level iSCSI initiator stacks, >> et al. I have not yet had a chance to look at Ronnie's code, but would >> be interested to understand how the threading model currently functions. >> >> Ronnie, I would recommending following Kevin's earlier advice and split >> your work into a reviewable series of commits (preferrably generated by >> git-format-patch) and repost the series for feedback to qemu-devel. You >> can read that as coded language for 'you will want to learn git to >> submit your patch', but it really does work. ;) > > Thanks, > > I will work on the suggestions over the weekend, so Ill resend either > this weekend or next weekend. > So don't spend/waste time reviewing now. > > As for the threading model. > Currently it is not threads safe, so all calls into the library would > have to be protected through a mutex if used from concurrent threads. > I couldn't see any such mutexes when looking at sheepdog as an > example, so do the block drivers need to be threads-safe in qemu? No, block drivers are not threaded currently. You don't have to take care of that yourself, everything is already protected by a mutex. > One goal of the library is to be 100% async and to never make any > blocking syscalls. > So the library will never block and should be able to reach good > performance, even with one single thread. That would match what other block drivers do. Kevin