qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/1] iscsi: add iSCSI block device support


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 1/1] iscsi: add iSCSI block device support
Date: Thu, 25 Nov 2010 10:30:50 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

Am 25.11.2010 06:22, schrieb ronnie sahlberg:
> Nicholas,
> below.
> 
> On Thu, Nov 25, 2010 at 3:32 PM, Nicholas A. Bellinger
> <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]