From csaba.henk@xxx Sun Dec 17 18:17:01 2006
Date: Sun, 17 Dec 2006 18:17:01 +0100
From: Csaba Henk <csaba.henk@xxx>
To: Anish Mistry <amistry@xxx>
Cc: fuse4bsd-devel@xxx, Yura Pakhuchiy <pakhuchiy@xxx>
Hi.
Funny it is. The fact that both you and Yura had the same problem with
by-and-large the same code snapshot is pretty misleading. Your problem
has nothing to do with 6.2-RC1 as such.
Indeed it has something to do with your kernel config. (For Yura I can't
precisely know that this was the problem, as he failed to send me his
config, but the symptoms strongly suggest this.)
You seem to be unaware of the following notification in
/usr/src/sys/conf/NOTES:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
#
# Enable extra debugging code for locks. This stores the filename and
# line of whatever acquired the lock in the lock itself, and change a
# number of function calls to pass around the relevant data. This is
# not at all useful unless you are debugging lock code. Also note
# that it is likely to break e.g. fstat(1) unless you recompile your
# userland with -DDEBUG_LOCKS as well.
#
options DEBUG_LOCKS
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
So recompile fstat with -DDEBUG_LOCKS. Apart from userland, the fuse
module also needs the appropriate defines. Therefore I added support for
building the module against a particular kernel config:
http://mercurial.creo.hu/repos/fuse4bsd-hg/?cmd=diffnodes;node0=22a2138b1ada;node1=c4785635e179;ref=c4785635e179
This is for the devel code though, therefore I attach hereby a patch which you
can apply against the release.
So apply the appropriate patch, and compile fuse4bsd so that you add a
"KERNCONF=BIGGUY" to your make parameters. From that on things will work
again, hopefully.
* * *
Now what to do about the port?
It's your task to make up your mind :) nevertheless I have some ideas.
1) Leave things as is and let users figure out this themselves?
2) Parse out the config of the acually running kernel from uname output
or from the kern.version sysctl?
3) Don't do anything but warn users to add the appropriate KERNCONF
value if they use a non-standard config?
Regarding 2): it could be done, eg., as follows:
take the output of
sysctl kern.version | head -2 | tail -1 | sed -n "s/.*@`hostname`://p"
If it's not empty, this could be passed to make as the vaule of
KERNCONFDIR (here KERCONFDIR, above KERNCONF, that's intentional!).
If it's empty then the kernel has been compiled on another machine and
the config may not be available.
However, 2) may not be appropriate at all if target system differs from
the currently running one.
I think the best would be adding a "make config" menu where one could
choose if s/he wants the value of KERCONFDIR being found out for the
currently running kernel as written above.
Csaba
diff -r c9549d324226 fuse_module/Makefile
--- a/fuse_module/Makefile Sat Feb 11 01:30:59 2006 +0200
+++ b/fuse_module/Makefile Sun Dec 17 17:37:42 2006 +0100
@@ -7,8 +7,12 @@ CFLAGS+=3D -DFMASTER
CFLAGS+=3D -DFMASTER
.endif
-.if defined(INVARIANTS)
-CFLAGS+=3D -DINVARIANTS
+.if defined(KERNCONF)
+KERNCONFDIR=3D /usr/obj/usr/src/sys/${KERNCONF}
+.endif
+
+.if defined(KERNCONFDIR)
+CFLAGS+=3D -DHAVE_KERNEL_OPTION_HEADERS -I${KERNCONFDIR}
.endif
.if defined(DEBUG)
diff -r c9549d324226 fuse_module/fuse_subr.c
--- a/fuse_module/fuse_subr.c Sat Feb 11 01:30:59 2006 +0200
+++ b/fuse_module/fuse_subr.c Sun Dec 17 17:37:42 2006 +0100
@@ -1,3 +1,5 @@
+#include "config.h"
+
#include <sys/types.h>
#include <sys/param.h>
#include <sys/systm.h>
diff -r c9549d324226 fuse_module/config.h
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/fuse_module/config.h Sun Dec 17 17:37:42 2006 +0100
@@ -0,0 +1,3 @@
+#ifdef HAVE_KERNEL_OPTION_HEADERS
+#include <opt_global.h>
+#endif
