From: William D Waddington <william.waddington@beezmo.com>
To: Mikael Pettersson <mikpe@csd.uu.se>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFCLUE2] 64 bit driver 32 bit app ioctl
Date: Fri, 24 Mar 2006 11:00:41 -0800 [thread overview]
Message-ID: <442441D9.6000507@beezmo.com> (raw)
In-Reply-To: <17442.53257.711022.424119@alkaid.it.uu.se>
Mikael Pettersson wrote:
> William D Waddington writes:
> > Apologies for dashing this off without the proper homework. My
> > customer is out of country doing an installation, and didn't test
> > this configuration first :(
> >
> > Customer is running RHEL3 on a 64 bit PC. Running the 64 bit kernel
> > and my 64 bit driver. They are calling the driver from their 32 bit
> > app. The driver supports a whole mess of ioctls.
> >
> > It seems that the kernel is trapping the 32-bit ioctl call and returning
> > an error to the app w/out calling the driver. It looks like
> > register_ioctl32_conversion() can convice the kernel that the driver can
> > handle 32-bit calls, but it has to be called for each ioctl cmd (??)
>
> In these old pre-compat_ioctl kernels you have to register each
> ioctl command individually. Yes that sucks. Live with it.
>
> > Putting aside (please) discussion of whether the kernel should presume
> > to hijack private ioctls, and whether I should be using the ioctl
> > interface at all (compatibility with app interface going back to 2.0
> > and SunOS) is there some way to make _one_ register call to indicate
> > that all my cmds are safe, or maybe an alternate ioctl entry point
> > that the kernel won't trap?
>
> Not as long as you're stuck with old 2.4 kernels. 2.6 kernels since
> 2.6.11-rc2 allow you to set up a single ->compat_ioctl() method,
> but not even RHEL4 has that yet.
Thanks,
It's working OK in my test cases: FC1/64 and the customer's RHEL3. I
just #include <asm/ioctl32.h> and register all my ioctls. Ugh.
The location of ioctl32.h seems to move from 2.4 kernel to kernel (and
distro to distro??). Any suggestion how to include in a universal way
and how to detect all the appropriate 64 bit configs for conditional
inclusion w/a 2.4 kernel? I detest #ifdef'd code but I guess I have to
do that too, or just keep one version around for this specific case :(
Thanks again,
Bill
--------------------------------------------
William D Waddington
Bainbridge Island, WA, USA
william.waddington@beezmo.com
--------------------------------------------
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch
next prev parent reply other threads:[~2006-03-24 19:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-23 15:06 [RFCLUE2] 64 bit driver 32 bit app ioctl William D Waddington
2006-03-23 16:42 ` Mikael Pettersson
2006-03-24 19:00 ` William D Waddington [this message]
2006-03-23 16:49 ` Arjan van de Ven
2006-03-23 16:57 ` Avi Kivity
2006-03-23 18:33 ` William D Waddington
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=442441D9.6000507@beezmo.com \
--to=william.waddington@beezmo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@csd.uu.se \
/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.