qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] KVM call minutes 2013-01-29


From: Paolo Bonzini
Subject: Re: [Qemu-devel] KVM call minutes 2013-01-29
Date: Tue, 29 Jan 2013 17:01:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

Il 29/01/2013 16:41, Juan Quintela ha scritto:
> * Replacing select(2) so that we will not hit the 1024 fd_set limit in the
>   future. (stefan)
> 
>   Add checks for fd's bigger than 1024? multifunction devices uses lot
>   of fd's for device.
> 
>   Portability?
>   Use glib?  and let it use poll underneath.
>   slirp is a problem.
>   in the end loop: moving to a glib event loop, how we arrive there is the 
> discussion.

We can use g_poll while keeping the main-loop.c wrappers around the glib
event loop.  Both slirp and iohandler.c access the fd_sets randomly, so
we need to remember some state between the fill and poll functions.  We
can use two main-loop.c functions:

int qemu_add_poll_fd(int fd, int events);

  select: writes the events into three fd_sets, returns the file
  descriptor itself

  poll: writes a GPollFD into a dynamically-sized array (of GPollFDs)
  and returns the index in the array.

int qemu_get_poll_fd_revents(int index);

  select: takes the file descriptor (returned by qemu_add_poll_fd),
  makes up revents based on the three fd_sets

  poll: takes the index into the array and returns the corresponding
  revents

iohandler.c can simply store the index into struct IOHandlerRecord, and
use it later.  slirp can do the same for struct socket.

The select code can be kept for Windows after POSIX switches to poll.

Paolo



reply via email to

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