Quote:
Originally posted by dan2003
I read earlier in this thread that it needed to be earlier than 2.4.18 IIRC to not suffer from the change in naming of the priv function. Has anybody got it working in a later kernel? Maybe if people could post the latest kernel they have it working in we could try to locate where the difference is and alter the r8180_if.c file accordingly. Maybe even hack the symbol names in the priv_part if necasary but i think all relavant stuff is exposed.
|
WARNING: long, boring, not-particularly relevant, technical explanation follows.
It's not a symbol name issue, it's a position issue.
In the official 2.4.23-pre1 kernel, the relevant data structure looks
something like this (excerpted from include/linux/netdevice.h):
struct net_device
{
...
/* List of functions to handle Wireless Extensions (instead of ioctl).
* See <net/iw_handler.h> for details. Jean II */
struct iw_handler_def * wireless_handlers;
struct ethtool_ops *ethtool_ops;
...
void *priv; /* pointer to private data */
...
}
The Realtek driver relies on "priv" to carry around stuff specific to its operation.
It even sets it up in source we can read (r8180_if.c, around line 85).
But the C compiler doesn't care about the name of "priv", only about it's
position in the "net_device" structure:
- In the 2.4.23-pre1 kernel, as above, "priv" is 108 bytes from the start (if I'm counting correctly).
- In the 2.4.20 kernel version, "ethtool_ops" isn't there, so "priv" is 104 bytes from the start.
- In the 2.4.18 kernel version, "wireless_handlers" isn't there either, so "priv" is 100 bytes from the start.
So whichever kernel the "priv_part.o" file was compiled with, that's the position that
the field has to be in for the driver to work correctly. If your kernel puts it in a different
position, "priv_part.o" won't find it, and so the driver won't work.
And that's just one minor change to one structure! Even if you managed to fix
this somehow, you'd probably only run into the next incompatible change. This
is the problem with binary drivers under Linux (or with Linux's development
philosophies, depending on your point of view).
User-space programs (eg, email clients, web browsers, text editors, etc) don't face these issues as much because the user/kernel
interfaces are much less fluid than the internal kernel interfaces (and most user-space programs use things like glibc as an intermediary to the kernel anyway).
. i assume some have had moreluck than this.
