qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/4] virtio-input: core code & base class


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 2/4] virtio-input: core code & base class
Date: Wed, 18 Mar 2015 17:58:32 +0100

On Wed, Mar 18, 2015 at 04:31:53PM +0100, Gerd Hoffmann wrote:
> On Mi, 2015-03-18 at 15:31 +0100, Michael S. Tsirkin wrote:
> > On Wed, Mar 18, 2015 at 03:00:12PM +0100, Gerd Hoffmann wrote:
> > > This patch adds virtio-input support to qemu.  It brings a abstract
> > > base class providing core support, other classes can build on it to
> > > actually implement input devices.
> > > 
> > > virtio-input basically sends linux input layer events (evdev) over
> > > virtio.
> > > 
> > > Signed-off-by: Gerd Hoffmann <address@hidden>
> > 
> > Two questions before I looked at code:
> > - can you do a writeup for the virtio spec?
> >   might make it easier to review.
> 
> >From cover letter:
> 
> <quote>
> 
> Guest driver:
>   https://www.kraxel.org/cgit/linux/log/?h=virtio-input
> 
> Specification:
>   https://www.kraxel.org/cgit/virtio-spec/log/?h=virtio-input
>   
> https://www.kraxel.org/virtio/virtio-v1.0-csprd03-virtio-input.html#x1-2640007
> 
> </quote>
> 
> Guess you havn't seen that (yet) because get_maintainers.pl doesn't
> really work for the cover letter, only the patches, and I forgot to cc
> you for the whole series.

Right. I didn't review yet, just saw it in my inbox and asked some
questions. I assumed there's no cover letter.

>  [ anyone has a solution for this btw? ]

I have a patch to git that makes it Cc everyone who's
copied on cover letter. This let you supply people
to Cc while editing the cover letter.

> > - does linux need to support this?
> 
> For pass-through (patch 4) yes, emulated hid devices (patch 3) not
> really.  It is linux only for now because the code simply #includes the
> system header files for the linux input layer, so it wouldn't compile on
> something else.
> 
> >   if yes we'll eventually want to take
> >   the header from there.
> 
> Yes, we can do that, for both linux input layer and virtio-input (once
> merged upstream) headers, then go build this on non-linux hosts too.
> 
> I'd suggest to do that as incremental patch, after guest driver merge.

Hmm but why? It's just code churn.

> >   maybe split out guest/host ABI?
> 
> When copying over virtio-input header from linux kernel that needs to
> happen anyway.
> 
> >   also might be a good idea to make style there
> >   linux-compliant (e.g. no typedefs, add typedefs
> >   in another header).
> 
> Linux driver linked above already has that.
> 
> cheers,
>   Gerd
> 



reply via email to

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