On 2011-09-27 16:54, Avi Kivity wrote:
> On 09/27/2011 05:50 PM, Jan Kiszka wrote:
>> On 2011-09-27 16:48, Avi Kivity wrote:
>>> On 09/27/2011 05:45 PM, Jan Kiszka wrote:
I don't disagree that there is still room for improving the existing
interface, generalizing to qemu_event. But tha
On 09/27/2011 09:54 AM, Avi Kivity wrote:
On 09/27/2011 05:50 PM, Jan Kiszka wrote:
On 2011-09-27 16:48, Avi Kivity wrote:
> On 09/27/2011 05:45 PM, Jan Kiszka wrote:
>> I don't disagree that there is still room for improving the existing
>> interface, generalizing to qemu_event. But that's not
On 09/27/2011 05:50 PM, Jan Kiszka wrote:
On 2011-09-27 16:48, Avi Kivity wrote:
> On 09/27/2011 05:45 PM, Jan Kiszka wrote:
>> I don't disagree that there is still room for improving the existing
>> interface, generalizing to qemu_event. But that's not in the scope of
>> this patch.
>>
>
>
On 2011-09-27 16:48, Avi Kivity wrote:
> On 09/27/2011 05:45 PM, Jan Kiszka wrote:
>> I don't disagree that there is still room for improving the existing
>> interface, generalizing to qemu_event. But that's not in the scope of
>> this patch.
>>
>
> Why not use event_notify.c?
It doesn't solve th
On 09/27/2011 05:45 PM, Jan Kiszka wrote:
I don't disagree that there is still room for improving the existing
interface, generalizing to qemu_event. But that's not in the scope of
this patch.
Why not use event_notify.c?
--
error compiling committee.c: too many arguments to function
On 2011-09-27 16:42, Avi Kivity wrote:
> On 09/27/2011 05:36 PM, Jan Kiszka wrote:
>> On 2011-09-27 16:34, Avi Kivity wrote:
>>> On 09/27/2011 05:29 PM, Jan Kiszka wrote:
>
> Moreover, the eventfd() counter is not lossy (practically speaking)
> whereas if
> you use pipe() as a
On 09/27/2011 05:36 PM, Jan Kiszka wrote:
On 2011-09-27 16:34, Avi Kivity wrote:
> On 09/27/2011 05:29 PM, Jan Kiszka wrote:
>>>
>>> Moreover, the eventfd() counter is not lossy (practically speaking)
whereas if
>>> you use pipe() as a counter, it will be lossy in practice.
>>>
>>> This i
On 09/27/2011 04:07 PM, Anthony Liguori wrote:
I think it's a bit dangerous to implement eventfd() in terms of pipe().
You don't expect to handle EAGAIN with eventfd() whereas you have to
handle it with pipe().
Moreover, the eventfd() counter is not lossy (practically speaking)
whereas if you
On 09/27/2011 09:22 AM, Jan Kiszka wrote:
On 2011-09-27 16:19, Anthony Liguori wrote:
On 09/27/2011 09:11 AM, Avi Kivity wrote:
On 09/27/2011 05:07 PM, Anthony Liguori wrote:
You don't expect to handle EAGAIN with eventfd() whereas you have to handle it
with pipe().
Moreover, the eventfd() c
On 2011-09-27 16:34, Avi Kivity wrote:
> On 09/27/2011 05:29 PM, Jan Kiszka wrote:
>>>
>>> Moreover, the eventfd() counter is not lossy (practically speaking)
>>> whereas if
>>> you use pipe() as a counter, it will be lossy in practice.
>>>
>>> This is why posix aio uses pipe() and not eventfd(
On 09/27/2011 09:29 AM, Jan Kiszka wrote:
On 2011-09-27 16:07, Anthony Liguori wrote:
On 09/27/2011 08:56 AM, Jan Kiszka wrote:
Move qemu_eventfd unmodified to oslib-posix and use it for signaling
POSIX AIO completions. If native eventfd suport is available, this
avoids multiple read accesses t
On 09/27/2011 05:29 PM, Jan Kiszka wrote:
>
> Moreover, the eventfd() counter is not lossy (practically speaking) whereas
if
> you use pipe() as a counter, it will be lossy in practice.
>
> This is why posix aio uses pipe() and not eventfd().
I don't get this yet. eventfd is lossy by default
On 2011-09-27 16:07, Anthony Liguori wrote:
> On 09/27/2011 08:56 AM, Jan Kiszka wrote:
>> Move qemu_eventfd unmodified to oslib-posix and use it for signaling
>> POSIX AIO completions. If native eventfd suport is available, this
>> avoids multiple read accesses to drain multiple pending signals. A
On 2011-09-27 16:19, Anthony Liguori wrote:
> On 09/27/2011 09:11 AM, Avi Kivity wrote:
>> On 09/27/2011 05:07 PM, Anthony Liguori wrote:
>>>
>>> You don't expect to handle EAGAIN with eventfd() whereas you have to handle
>>> it
>>> with pipe().
>>>
>>> Moreover, the eventfd() counter is not lossy
On 09/27/2011 05:19 PM, Anthony Liguori wrote:
qemu_event_create()
qemu_event_signal()
qemu_event_wait()
qemu_event_poll_add() // registers in main loop
qemu_event_poll_del()
See hw/event_notifier.[ch].
Precisely.
--
error compiling committee.c: too many arguments to function
On 09/27/2011 09:11 AM, Avi Kivity wrote:
On 09/27/2011 05:07 PM, Anthony Liguori wrote:
You don't expect to handle EAGAIN with eventfd() whereas you have to handle it
with pipe().
Moreover, the eventfd() counter is not lossy (practically speaking) whereas if
you use pipe() as a counter, it wi
On 09/27/2011 05:07 PM, Anthony Liguori wrote:
You don't expect to handle EAGAIN with eventfd() whereas you have to
handle it with pipe().
Moreover, the eventfd() counter is not lossy (practically speaking)
whereas if you use pipe() as a counter, it will be lossy in practice.
This is why p
On 09/27/2011 08:56 AM, Jan Kiszka wrote:
Move qemu_eventfd unmodified to oslib-posix and use it for signaling
POSIX AIO completions. If native eventfd suport is available, this
avoids multiple read accesses to drain multiple pending signals. As
before we use a pipe if eventfd is not supported.
Move qemu_eventfd unmodified to oslib-posix and use it for signaling
POSIX AIO completions. If native eventfd suport is available, this
avoids multiple read accesses to drain multiple pending signals. As
before we use a pipe if eventfd is not supported.
Signed-off-by: Jan Kiszka
---
os-posix.c
19 matches
Mail list logo
