From owner-freebsd-hackers  Wed Apr 30 04:48:31 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id EAA22566
          for hackers-outgoing; Wed, 30 Apr 1997 04:48:31 -0700 (PDT)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA22561
          for <hackers@FreeBSD.org>; Wed, 30 Apr 1997 04:48:28 -0700 (PDT)
Message-Id: <199704301148.EAA22561@hub.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA003290857; Wed, 30 Apr 1997 21:47:37 +1000
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...)
To: bde@zeta.org.au (Bruce Evans)
Date: Wed, 30 Apr 1997 21:47:37 +1000 (EST)
Cc: hackers@FreeBSD.org
In-Reply-To: <199704301005.UAA15798@godzilla.zeta.org.au> from "Bruce Evans" at Apr 30, 97 08:05:42 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from Bruce Evans, sie said:
> 
> >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.

Why ?  Why do we need to change something that already works ?
Especially since all other LKM implementations do what 2.1.x does
now anyway.  If you want to do something, fix post 2.1.x to work
safely in the same fashion as 2.1.x.

IMHO, the driver should need to know zero about devsw tables, etc.

With people suggesting more and more ad hoc changes, that mean more
work for me, I seriously have to wonder "is it worth the effort ?"

Darren