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"

Reply via email to