All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Henrik Rydberg" <rydberg@euromail.se>
To: Kevin Daughtridge <kevin@kdau.com>
Cc: Jiri Slaby <jslaby@suse.cz>, Jiri Kosina <jkosina@suse.cz>,
	linux-input@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] HID: leave dev_rdesc unmodified and use it for comparisons
Date: Wed, 19 Sep 2012 20:32:31 +0200	[thread overview]
Message-ID: <20120919183231.GA603@polaris.bitmath.org> (raw)
In-Reply-To: <5059F872.3080203@kdau.com>

Hi Kevin,

Thanks for looking to this.

> Hmm. I hadn't noticed that the other drivers are returning a static
> structure. In that case, it seems that report_fixup itself is broken
> from a memory perspective, in that it returns pointers to
> inconsistent storage types depending on the driver.

The driver can either modify the existing buffer, of return a pointer
to a buffer managed by the driver. The former requires a kmemdup
before, the latter a kmemdup after.

> 1. Ugly workaround: make a temporary copy of the dev_rdesc, give it
> to report_fixup, make a copy of the return, store that copy in
> rdesc, free the temporary copy. Though ugly, this would at least
> involve the smallest diff.

Yes, it is correct and ugly, in no particular order.

> 2. Standardize the behavior of the drivers' report_fixup
> implementations. Given that some of them need to change the size of
> the descriptor, modifying the passed structure is not an option.
> Probably all of them should return a newly allocated structure,
> either a modified copy of the input or a copy of their static, that
> can then be stored directly in rdesc. Especially since report_fixup
> is only ever called right before a copy is going to be taken anyway.

Relying on the returned pointer to be properly alloc'd is not a good
idea, in particular since it changes semantics rather drastically.

Since the current function performs two different things, perhaps
there should be two different functions instead.

> (Adding constness to a parameter isn't considered a severe ABI
> break, is it?)

Inside the kernel there is no ABI. Go wild.

Thanks,
Henrik

  reply	other threads:[~2012-09-19 18:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-19  2:36 [PATCH v2] HID: leave dev_rdesc unmodified and use it for comparisons Kevin Daughtridge
2012-09-19  8:05 ` Jiri Slaby
2012-09-19 16:53   ` Kevin Daughtridge
2012-09-19 18:32     ` Henrik Rydberg [this message]
2012-09-19 11:47 ` Sergei Shtylyov
2012-09-19 11:55 ` Jiri Kosina

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=20120919183231.GA603@polaris.bitmath.org \
    --to=rydberg@euromail.se \
    --cc=jkosina@suse.cz \
    --cc=jslaby@suse.cz \
    --cc=kevin@kdau.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.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.