Re: getting rid of sys/nfs/nfs_lock.c

Dennis Clarke wrote:
>On 12/28/19 7:30 PM, Rick Macklem wrote:
>> Hi,
>>
>> sys/nfs/nfs_lock.c uses Giant. Since it has not been used by default since
>> March 2008, I suspect it can be removed from head without any impact.
>> Post March 2008, the only way this code could be executed is by both
>> building a kernel without "options NFSLOCKD" and deleting nfslockd.ko
>> from the kernel boot directory and then running rpc.lockd on the system.
>>
>> I doubt anyone has been doing both of the above, but if you think it is
>> still useful, please speak up. (I have an untested patch that replaces Giant
>> with a regular mutex. I realized this code is not used when I trying to test it.;-)
>>
>> Also, if it seems appropriate, I could commit a patch that makes it print out
>> "deprecated and going away before FreeBSD 13" message, but I doubt anyone
>> will ever see it.
>> Should I do such a message and wait a few months for the deletion?
>
>Such a message is a good idea.
>
>I am curious if there is any way in which we would see that message when
>creating an NFS share via ZFS set sharenfs='foo' ?
Only if your kernel was built without "options NFSLOCKD" and you do not
have nfslockd.ko in your kernel boot directory.
Highly unlikely for amd64, since neither of the above would be true unless
you created a custom kernel config and deleted nfslockd.ko from the kernel
boot directory you installed it in.

It is slightly more likely to occur for an arm installation, since many of those
do not configure NFS into the kernel, if you did not have the modules in the
boot directory and you then started rpc.lockd.

rick


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
_______________________________________________
freebsd-current_at_freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"