All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-dev@lists.oasis-open.org,
	virtualization@lists.linux-foundation.org,
	David Herrmann <dh.herrmann@gmail.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:ABI/API" <linux-api@vger.kernel.org>
Subject: Re: [virtio-dev] Re: [PATCH v3] Add virtio-input driver.
Date: Tue, 24 Mar 2015 12:46:21 +0100	[thread overview]
Message-ID: <1427197581.18768.16.camel@nilsson.home.kraxel.org> (raw)
In-Reply-To: <20150324105829-mutt-send-email-mst@redhat.com>

  Hi,

> > +	spin_lock_irqsave(&vi->lock, flags);
> > +	while ((event = virtqueue_get_buf(vi->evt, &len)) != NULL) {
> > +		input_event(vi->idev,
> > +			    le16_to_cpu(event->type),
> > +			    le16_to_cpu(event->code),
> > +			    le32_to_cpu(event->value));
> 
> What happens if input layer gets an
> unexpected event code or value?

input layer checks it and ignores events not supported (according to the
support bitmaps).

> > +static int virtinput_send_status(struct virtio_input *vi,
> > +				 u16 type, u16 code, s32 value)
> > +{

> This means that caller will get errors if it happens to call
> send_status at a rate that's faster than host's consumption of them.
> To me this looks wrong.
> Poking at input layer, it seems to simply discard errors.
> Is it always safe to discard status updates?

Typical use case is updating the leds of your keyboard.  Loosing one
update isn't the end of the world.  Also that are _very_ low rate
events, and in case that really actually happens you likely have bigger
problems anyway ;)

> > +static void virtinput_cfg_bits(struct virtio_input *vi, int select, int subsel,
> > +			       unsigned long *bits, unsigned int bitcount)
> > +{
> > +	unsigned int bit;
> > +	size_t bytes;
> > +	u8 *virtio_bits;
> > +
> > +	bytes = virtinput_cfg_select(vi, select, subsel);
> > +	if (!bytes)
> > +		return;
> 
> How about limiting bytes to sizeof struct virtio_input_config->u?

It's limited to 256 anyway because size is u8 in config space.

> > +	size = virtinput_cfg_select(vi, VIRTIO_INPUT_CFG_ID_DEVIDS, 0);
> > +	if (size >= 8) {
> 
> What does 8 mean here? Should be sizeof virtio_input_devids?

Yes, fixed.

> > +struct virtio_input_config {
> > +	__u8    select;
> > +	__u8    subsel;
> > +	__u8    size;
> > +	__u8    reserved;
> > +	union {
> > +		char string[128];
> > +		__u8 bitmap[128];
> 
> I note that neither string nor bitmap are used by
> driver. What are they in aid of?

Fixed.  Just sloppy coding, the name should use u.string, the bitmap
u.bitmap, instead of just "u" (although for offsetof it doesn't make a
difference).

cheers,
  Gerd



  parent reply	other threads:[~2015-03-24 11:46 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-24  7:32 [PATCH v3] Add virtio-input driver Gerd Hoffmann
2015-03-24  7:32 ` Gerd Hoffmann
2015-03-24 10:26 ` Gerd Hoffmann
2015-03-24 10:26   ` Gerd Hoffmann
2015-03-24 10:40   ` Michael S. Tsirkin
2015-03-24 10:40   ` Michael S. Tsirkin
2015-03-24 10:48   ` Michael S. Tsirkin
2015-03-24 10:48     ` Michael S. Tsirkin
2015-03-24 10:26 ` Gerd Hoffmann
2015-03-24 10:36 ` Michael S. Tsirkin
2015-03-24 11:46   ` [virtio-dev] " Gerd Hoffmann
2015-03-24 11:46   ` Gerd Hoffmann [this message]
2015-03-24 13:02     ` Michael S. Tsirkin
2015-03-24 13:02       ` Michael S. Tsirkin
2015-03-24 13:37       ` Gerd Hoffmann
2015-03-24 13:37       ` Gerd Hoffmann
2015-03-24 13:37         ` Gerd Hoffmann
2015-03-24 14:14         ` Michael S. Tsirkin
2015-03-24 15:25           ` Gerd Hoffmann
2015-03-24 15:25             ` Gerd Hoffmann
2015-03-24 16:05             ` Dmitry Torokhov
2015-03-24 16:05               ` Dmitry Torokhov
2015-03-24 14:14         ` Michael S. Tsirkin
2015-03-24 16:23   ` Dmitry Torokhov
2015-03-24 16:23     ` Dmitry Torokhov
2015-03-24 17:22     ` Michael S. Tsirkin
2015-03-24 17:22       ` Michael S. Tsirkin
2015-03-24 17:28       ` Dmitry Torokhov
2015-03-24 17:28         ` Dmitry Torokhov
2015-03-25  5:36         ` Michael S. Tsirkin
2015-03-25  5:36         ` Michael S. Tsirkin
2015-03-24 10:36 ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1427197581.18768.16.camel@nilsson.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=dh.herrmann@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.