Re: [PATCH] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_PIPE

[Sasha Levin <levinsasha928@gmail.com>]

On Mon, 2011-07-04 at 17:59 +0300, Avi Kivity wrote:
> On 07/04/2011 05:52 PM, Sasha Levin wrote:
> > >
> > >  I can't really see that as useful.  eventfds destroy information;
> > >  without datamatch, you have no idea what value was written.  Even with
> > >  datamatch, you have no idea how many times it was written.  With a
> > >  range, you also have no idea which address was written.  It's pretty
> > >  meaningless.
> > >
> >
> > It is pretty useless, but I didn't want the ioctl to behave differently
> > when passing a socket or an eventfd.
> >
> > If we do go for a new ioctl as you suggested then yes, problem solved.
> >
> 
> Yes.  I guess it depends on the numbers of if () s introduced into the 
> code.  If it starts to feel dirty, split it into a separate ioctl (they 
> can both call common helpers).
> 
> It's fine to allow size > 8 for eventfds.  Yes it's meaningless, but 
> it's not harmful and I can't see it breaking anything.  Note that we may 
> need to change the way we do matches - currently 'size' means the access 
> size, with an exact match on the address, but the new meaning is 'any 
> address from start to start+size-1'.
> 

Looks like there was no need for a new ioctl. I've tried going further
with adding 'meaningless' features to the existing implementation so
that the sockets could be added without needing a new mechanism.

I've added a user configurable 'read' flag which is supposed to trigger
an event when the memory is read and a 'nowrite' flag which won't
trigger an event on a write. This makes it possible to add sockets while
keeping the code pretty much the same.

Instead of making these flags user configurable, they could be
implicitly defined according to the choice of eventfd or socket, I
couldn't decide which method was better so just went with the first one.

-- 

Sasha.