From owner-freebsd-hackers  Wed Apr 30 03:13:08 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id DAA19801
          for hackers-outgoing; Wed, 30 Apr 1997 03:13:08 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA19794
          for <hackers@freebsd.org>; Wed, 30 Apr 1997 03:13:03 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id UAA15798; Wed, 30 Apr 1997 20:05:42 +1000
Date: Wed, 30 Apr 1997 20:05:42 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199704301005.UAA15798@godzilla.zeta.org.au>
To: avalon@coombs.anu.edu.au, msmith@atrad.adelaide.edu.au
Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...)
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>Hmm, I didn't see that before.  It doesn't look like it's used
>correctly though; eg. the qcam module hooks itself in rather than
>letting _lkm_dev() do it.
>
>Then when its load function returns happily, the bogus entries its
>made in the cdevsw are saved as the 'old' values, and thus when it's 
>unloaded the saved values are restored and everything is spam.

Right (except _lkm_dev() shouldn't do it).

The olddev stuff is bogus except in 2.1.x.  The `old' pointer is
guaranteed to be null, or at least should have been null (SYSINIT() is
misused to initiate the devsw entries for unattached drivers).  There
are no functions to remove devsw entries, but "add"ing null entries
works.

_lkm_dev() shouldn't be touching the devsw's.  Drivers need to manage
the devsw's directly for the non-LKM case and should use identical
code for the LKM case.

Bruce