From: Egbert Eich <eich@pdx.freedesktop.org>
To: dri-devel@lists.sourceforge.net
Cc: Greg KH <greg@kroah.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: From Eric Anholt:
Date: Thu, 13 May 2004 18:54:04 +0200 [thread overview]
Message-ID: <16547.43052.87943.11064@xf11.fra.suse.de> (raw)
In-Reply-To: torvalds@osdl.org wrote on Wednesday, 12 May 2004 at 15:32:12 -0700
Linus Torvalds writes:
>
>
> On Wed, 12 May 2004, Dave Airlie wrote:
> >
> > I just looked at drm.h and nearly all the ioctls use int, this file is
> > included in user-space applications also at the moment, I'm worried
> > changing all ints to __u32 will break some of these, anyone on DRI list
> > care to comment?
>
> Right now, all architectures have "int" being 32-bit, so nothing should
> break. Apart from sign issues, of course.
>
> If there are pointers and "long", then those should just not exist. Never
> expose kernel pointers to user mode (and you really never should pass user
> pointers back), and "long" should really just be "__u32" instead (since
> that is what it is on a 32-bit platform - and if it works there, then it
> should work on a 64-bit platform too).
>
Unfortunately this is done in some places in DRM. Pointers are used as a
simple 'handle' to point to areas that are to be mapped by mmap()
from user mode.
I've done some ioctl32() interfaces for DRM for a few drivers (mga,
radeon, r128) to make 32bit software work on 64bit systems such as AMD64.
In most cases it was easy to work around the longs as they either did
not have to exist at all or could be replaced by something that's
platform independent.
I have plans to submit these ioctl32() interfaces to Mesa when I get
around to do it.
Anyway they are unnecessary kludges which should have been avoided
from the beginning.
Egbert.
prev parent reply other threads:[~2004-05-13 16:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200405112211.i4BMBQDZ006167@hera.kernel.org>
2004-05-11 22:22 ` Greg KH
2004-05-11 23:17 ` Dave Airlie
2004-05-11 23:20 ` Dave Airlie
2004-05-11 23:34 ` Valdis.Kletnieks
2004-05-11 23:43 ` Greg KH
2004-05-12 0:07 ` Daniel Jacobowitz
2004-05-12 0:12 ` Greg KH
2004-05-12 0:12 ` H. Peter Anvin
2004-05-11 23:46 ` ioctls in drm.h Dave Airlie
2004-05-13 1:39 ` From Eric Anholt: Eric Anholt
2004-05-12 1:07 ` Jon Smirl
2004-05-12 1:15 ` Greg KH
2004-05-12 22:32 ` Linus Torvalds
2004-05-13 16:54 ` Egbert Eich [this message]
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=16547.43052.87943.11064@xf11.fra.suse.de \
--to=eich@pdx.freedesktop.org \
--cc=dri-devel@lists.sourceforge.net \
--cc=greg@kroah.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®