I didn't get much (read: any) feedback from the freebsd-emulation list
on this, so i'm passing it on myself. My original post can be found at:
http://lists.freebsd.org/pipermail/freebsd-emulation/2003-August/000136.html
A few days ago, i found myself in need of mounting a vmware image on my
old 4.7-STABLE system. To do this, i needed linprocfs functioning
properly, but this module failed with an "exec format error". Further
investigation revealed that nextpid was undefined. So i checked the
source, and discovered that in kern/kern_fork.c, nextpid was defined
statically. It was defined nowhere else, but in
i386/linux/linprocfs/linprocfs_misc.c, it was declared "extern".
Since the system needed a new pair of shoes anyway, i promptly upgraded
it to 4.8-STABLE. To my surprise, i found that nothing had changed.
The nextpid variable was still defined as a "static int" in
kern_fork.c,
and it was still requested externally in linprocfs.c. And, obviously,
the module still couldn't be loaded. I removed the "static" tag
in
kern_fork.c, recompiled, and everything was fine.
What's odd isn't that this wasn't functioning properly. What's
odd is
that it _does_ function properly for some. Indeed, i also have a
4.8-RELEASE system, using the very same tidbits of code, and
linprocfs.ko loads perfectly. In the working module, nm reports that
nextpid is still undefined, and in the otherwise linked kernel, nm
reports that nextpid is still a local variable:
% nm -A /modules/linprocfs.ko /kernel |grep nextpid
/modules/linprocfs.ko: U nextpid
/kernel:c02c9298 d nextpid
I'm not sure why this would have been unchanged from 4.7-STABLE to
4.8-STABLE, as it shouldn't work for _anyone_, barring some compiler bug
that exports static variables. In the RELENG_5 kernel tree, the
'nextpid' variable has been changed to 'lastpid', and the static
declaration has been removed.
So there we have it. I believe it's a bug. Twofold, that is. A bug
that it works at all, and a bug that when it works correctly, it
doesn't.
ari
