Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Jul 2012 22:37:29 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Fabian Keil <freebsd-listen@fabiankeil.de>
Cc:        freebsd-hackers@FreeBSD.org, Sean Bruno <sbruno@FreeBSD.org>, rmacklem@FreeBSD.org
Subject:   Re: dtraceall.ko with old nfsclient
Message-ID:  <4FFC8479.9080608@FreeBSD.org>
In-Reply-To: <20120710205702.5e57168b@fabiankeil.de>
References:  <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FFC8479.9080608>