-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 13 Jul 1999, Pieter Krul wrote:
> In the syslog:
> xenon kernel: sys32_ioctl: Unknown cmd fd(3) cmd(0000541e) arg(effffa50)
>
> which seems to come from around arch/sparc64/kernel/ioctl32.c
i have a similar problem on my ultra-1. the problem, as near as i can
figure, is that while the kernel is 64-bit code, the userland programs are
all 32-bit code. the code in ioctl32.c is responsible for translating
32-bit ioctl() calls to the appropriate 64-bit function call within the
kernel, and some of the numeric functions used by some modules haven't
been written into this kernel yet.
there's also the issue that several modules within the kernel use the same
ioctl() function numbers- do "man ioctl_list | egrep 89E0" and you'll see
that, even according to the official documentation, four different
functions are using 000089E0 as their function-identifier (the second
parameter to ioctl().)
i don't know if this is a bug just in ioctl32.c, or if it's just a bad
design decision (or lack of decision) on the part of the kernel team, but
it's preventing other things from working.
the issue that brought it to my attention was when i tried to compile
"vpnd", which is a program that creates an encrypted IP-tunnel by turning
a socket into a pty, and then running slip over that pty. one of the
ioctl() calls for configuring the slip interface happens to have the same
function number as the EQL_ENSLAVE function, used to add a physical
interface to a virtual "bundle" of interfaces when the EQL module is
present in the kernel. (does anyone still use this module?)
since sys32_ioctl() is essentially a large switch() statement based on
just the numeric function id, i don't see an easy fix for this... unless
maybe if you keep a list of the ioctl() handlers in each kernel module,
and have sys32_ioctl() call each one in order until it finds one that
recognizes the function and handles it? this would involve keeping a
linked list of function handlers, and each module would have to somehow
add itself to this list- it seems a bit much to be added into the general
module mechanism just to support one platform.
of course the real solution would be to have a real sparc64 compiler that
would allow people to run true 64-bit code, like the alpha boxes (a friend
here in the office is running alpha-linux and never lets me forget that
there is no 32-bit code on his machine at all...)
take care all.
- ------------------------------------------------------------------------------
| John Simpson, Programmer At Large | http://www.depeche.mode.net/~jms1/ |
- ------------------------------------------------------------------------------
| It all seems so stupid, it makes me want to give up. |
| But why should I give up when it all seems so stupid? |
- ------------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.8 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE3jJLKcI1+np7dUdkRAg87AKDqB4ngt/vNPhKpSkwI0SiDoqxWQACgptLy
Osi4hGTQ5YARZaxTYXY8BGQ=
=stR3
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of the message to [EMAIL PROTECTED]
