From owner-freebsd-current  Sat Nov  7 08:07:09 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id IAA12778
          for freebsd-current-outgoing; Sat, 7 Nov 1998 08:07:09 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA12765
          for <freebsd-current@FreeBSD.ORG>; Sat, 7 Nov 1998 08:07:04 -0800 (PST)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id DAA02999;
	Sun, 8 Nov 1998 03:06:27 +1100
Date: Sun, 8 Nov 1998 03:06:27 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199811071606.DAA02999@godzilla.zeta.org.au>
To: dfr@nlsystems.com, wollman@khavrinen.lcs.mit.edu
Subject: Re: nfs.ko panics on unloading
Cc: abial@nask.pl, freebsd-current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>> > code).  Unfortunately the vfs system itself doesn't support unloading yet 
>> > (a project for someone there).
>> 
>> It certainly did before!  NFS never did, no, because there was no way
>> to undefine a syscall, but when I first implemented VFS LKMs, you
>> definitely could unload them (provided that the reference count was
>> zero).
>
>I must be blind! I didn't even see vfs_unregister().  I'll tweak my patch

I fixed most of the unloading problems in the NFS LKM before 3.0R.  See
nfs_uninit().

Most vfs's, including nfs, don't actually support unloading, because
of bitrot in malloc() -- malloc_init() creates pointers that are left
dangling after unload.

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message