From: Arnd Bergmann <arnd@arndb.de>
To: Andi Kleen <andi@firstfloor.org>
Cc: Dave Airlie <airlied@gmail.com>,
David Miller <davem@davemloft.net>,
airlied@linux.ie, dri-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: is avoiding compat ioctls possible?
Date: Wed, 18 Nov 2009 15:42:05 +0100 [thread overview]
Message-ID: <200911181542.05152.arnd@arndb.de> (raw)
In-Reply-To: <20091118090913.GA9505@basil.fritz.box>
On Wednesday 18 November 2009, Andi Kleen wrote:
> > Doing all these out-of-line hidden over here in a separate file just
> > seems crazy,
> > and I'm having trouble wondering why ppl consider it a better idea at all.
>
> The separate file is on the way out, the modern way is to use
> ->compat_ioctl in the driver itself. Near all drivers except
> for a few exceptions like DRM put it into the same file.
> I think you should just move the code around in DRM too
> and drop the separate file.
Right. Commonly, you can simply handle the incompatible stuff in
->compat_ioctl and then call the regular function. Another way to
do it if you want to consolidate even more is to pass a flag down
the actual function and do
static int my_common_ioctl(struct my_object *my, unsigned int cmd, unsigned long arg,
void __user *argp, int compat)
{
...
}
static long my_native_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
return my_commmon_ioctl(file->private_data, cmd, arg, (void __user *)arg, 0);
}
static long my_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
return my_commmon_ioctl(file->private_data, cmd, arg, compat_ptr(arg), 1);
}
Doing that, you can have the ioctl handling for a subsystem consolidated in one
place, just doing the copy_from_user() part separately.
For the specific case of drm, where you have a table with all the ioctls, I can
see yet another option: add another function pointer to 'struct drm_ioctl_desc'
that does the conversion, e.g.
int drm_version_compat(void __user *argp, void *kdata, int dir)
{
struct compat_drm_version __user *uversion = argp;
struct compat_drm_version cversion;
struct drm_version *version = kdata;
if (dir == IOC_IN) {
if (copy_from_user(&cversion, uversion, sizeof(cversion);
return -EFAULT;
*version = (struct drm_version) {
.version_major = cversion.version_major,
.version_minor = cversion.version_minor,
.version_mpatchlevel = cversion.version_patchlevel,
.name_len = cversion.name_len,
.name = compat_ptr(cversion.name),
.date_len = cversion.date_len,
.date = compat_ptr(cversion.date),
.desc_len = cversion.desc_len,
.desc = compat_ptr(cversion.desc),
};
return 0;
} else if (dir == IOC_OUT) {
cversion = (struct drm_version) {
.version_major = version->version_major,
.version_minor = version->version_minor,
.version_mpatchlevel = version->version_patchlevel,
.name_len = version->name_len,
.name = (unsigned long)version->name,
.date_len = version->date_len,
.date = (unsigned long)version->date,
.desc_len = version->desc_len,
.desc = (unsigned long)version->desc,
};
if (copy_to_user(uversion, &cversion, sizeof(cversion);
return -EFAULT;
return 0;
}
return -EINVAL;
}
static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, drm_version_compat, 0),
...
};
Arnd <><
next prev parent reply other threads:[~2009-11-18 14:42 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-28 1:22 is avoiding compat ioctls possible? Dave Airlie
2009-10-28 2:25 ` David Miller
2009-10-28 3:01 ` Dave Airlie
2009-10-28 2:53 ` Andi Kleen
2009-10-28 3:05 ` Dave Airlie
2009-10-28 3:19 ` Andi Kleen
2009-10-28 3:28 ` Dave Airlie
2009-10-28 3:34 ` Andi Kleen
2009-10-28 3:43 ` David Miller
2009-10-28 3:41 ` David Miller
2009-10-28 21:05 ` Maciej W. Rozycki
2009-10-29 8:27 ` Arnd Bergmann
2009-10-28 3:38 ` David Miller
2009-10-28 3:43 ` Dave Airlie
2009-10-28 3:45 ` David Miller
2009-10-28 3:51 ` Andi Kleen
2009-10-28 3:54 ` Dave Airlie
2009-10-28 5:28 ` David Miller
2009-10-28 5:42 ` Dave Airlie
2009-10-28 6:04 ` David Miller
2009-10-28 7:53 ` David Miller
2009-10-28 7:59 ` Andi Kleen
2009-10-28 8:11 ` David Miller
2009-10-28 8:19 ` Andi Kleen
2009-10-28 8:28 ` David Miller
2009-10-28 12:13 ` Arnd Bergmann
2009-10-28 12:16 ` David Miller
2009-10-28 15:40 ` Arnd Bergmann
2009-10-29 5:41 ` David Miller
2009-10-29 8:16 ` Arnd Bergmann
2009-10-29 8:34 ` Heiko Carstens
2009-10-29 8:39 ` David Miller
2009-10-28 12:17 ` David Miller
2009-10-30 1:13 ` Dave Airlie
2009-10-30 10:13 ` Arnd Bergmann
2009-11-18 0:26 ` Dave Airlie
2009-11-18 9:09 ` Andi Kleen
2009-11-18 14:42 ` Arnd Bergmann [this message]
2009-10-28 3:37 ` David Miller
2009-10-28 4:36 ` Andi Kleen
2009-10-28 5:29 ` David Miller
2009-10-28 10:27 ` Arnd Bergmann
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=200911181542.05152.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=airlied@gmail.com \
--cc=airlied@linux.ie \
--cc=andi@firstfloor.org \
--cc=davem@davemloft.net \
--cc=dri-devel@lists.sourceforge.net \
--cc=linux-kernel@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.