[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 4/4] qemu-nbd: do not start the block layer in t
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH 4/4] qemu-nbd: do not start the block layer in the parent |
Date: |
Fri, 04 Nov 2011 11:31:57 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 |
Am 04.11.2011 10:46, schrieb Paolo Bonzini:
> On 10/28/2011 02:17 PM, Paolo Bonzini wrote:
>>> Yes, it would be better if we could have error output on stderr. Now,
>>> "simple" errors such as a missing image file (or wrong path to the
>>> image) are reported to syslog instead. It could be the source of some
>>> headaches...
>>>
>>> Is there a way we could have the child send the error to the parent
>>> over a pipe and have the parent print it on stderr?
>>
>> A way could be to change the fork() into a separate thread, so that you
>> can daemonize as soon as you accept the socket rather than having to do
>> it early.
>
> I tried implementing this, but in general daemonization (which forks and
> leave only the children) breaks the threading.
>
> So we could either keep this series (which moves all errors to syslog,
> but doesn't otherwise change behavior), or I can finish and post an
> alternative series that removes all forking from qemu-nbd *but* changes
> behavior in that "qemu-nbd -c" will not daemonize anymore.
>
> Since this is 1.0 after all, I'm slightly more inclined towards the latter.
>
> Opinions? Kevin, Anthony?
I'm surprised that -c is what causes trouble. As far as I understand,
the code for implementing -c doesn't use the qemu block layer at all.
So why can't we just change the code to fork before it initialises the
block layer and opens the image file?
Kevin