DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=gg5CcWqC+Dx5VBOCKMAW+sub2HvAXj3KJ0BmWNWZJOjCPtk99ruRxSkQrtlhLdiezJ
         oGVb0hP6H/0Wg/zKYTenYbyFjQAGmag/4CeSCczHgKFeS77v74K3xUWWMO664RiozEu6
         jMKiBUvTr9Gs9RMQVdjThZB2PV+njlc3iWhEs=
MIME-Version: 1.0
Date: Wed, 28 Oct 2009 11:22:18 +1000
Message-ID: <21d7e9970910271822p3751b2fdnd78e1bc3326b9b0b@mail.gmail.com>
Subject: is avoiding compat ioctls possible?
From: Dave Airlie <airlied@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>,
       DRI Development Mailing List 
	<dri-devel@lists.sourceforge.net>,
       Arnd Bergmann <arnd@arndb.de>, David Miller <davem@davemloft.net>
Content-Type: text/plain; charset=ISO-8859-1
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 903
Lines: 21

So for drm KMS we wrote a bunch of ioctls that were 64-bit clean in theory.

They used uint64_t to represent userspace pointers and userspace
casted into those and the kernel casts back out and passes it to copy_*_user

Now I thought cool I don't need to worry about compat ioctl hackery I can
run 32 on 64 bit apps fine and it'll all just work.

Now Dave Miller points out that I'm obivously deluded and we really need
to add compat ioctls so that the kernel can truncate correctly 32-bit address
in case userspace shoves garbage into the top 32bits of the u64.

Is there really no way to avoid compat ioctls? was I delusional in
thinking there was?

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/