on 10/07/2012 21:57 Fabian Keil said the following: > I do not use a completely NFS-free kernel, but I don't build any > NFS-related modules. Trying to load an unpatched dtraceall results in: > > Jul 9 21:58:48 r500 sudo: fk : TTY=pts/16 ; PWD=/home/fk ; USER=root > ; COMMAND=/sbin/kldload dtraceall Jul 9 21:58:48 r500 kernel: [8922] KLD > dtnfsclient.ko: depends on oldnfs - not available or version mismatch Jul > 9 21:58:48 r500 kernel: [8922] linker_load_file: Unsupported file type Jul > 9 21:58:48 r500 kernel: [8922] KLD dtraceall.ko: depends on dtnfsclient - > not available or version mismatch Jul 9 21:58:48 r500 kernel: [8922] > linker_load_file: Unsupported file type > > My assumption was that your patch and the "#elif defined (NFSCLIENT)" would > fix that, and indeed it does, but I later on realized that I actually do > have NFSCL in the kernel: > > fk@r500 /usr/src $sysctl kern.conftxt | grep NFS options NFS_ROOT options > NFSLOCKD options NFSD options NFSCL > > My impression is that the patch is missing an opt_nfs.h inclusion combined > with the Makefile voodoo to create the file. > > The dtraceall module already has an opt_compat.h, even though the Makefile > logic to create it seems a bit dubious to me. It blindly assumes that > COMPAT_FREEBSD32 is available on amd64.
Not sure if I got correctly what the (perceived) problem actually is, but I have this to say: the proper way of building a module is either via buildkernel (MODULES_OVERRIDE, etc) or by using KERNBUILDDIR for "independent" module build if the module has any dependency on kernel options in effect. This could be a little bit sad (for third-party module providers), but this seems to be true. Sometimes Makefile-s fake kernel options for truly independent module build (no KERNBUILDDIR) to provide the widest and/or safest feature set. But this has to be done very carefully to ensure that module<->kernel*s* compatibility actually occurs. -- Andriy Gapon _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"