From owner-freebsd-hackers  Wed Apr 30 06:11:16 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id GAA25292
          for hackers-outgoing; Wed, 30 Apr 1997 06:11:16 -0700 (PDT)
Received: from who.cdrom.com (who.cdrom.com [204.216.27.3])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA25287
          for <hackers@FreeBSD.org>; Wed, 30 Apr 1997 06:11:14 -0700 (PDT)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by who.cdrom.com (8.8.5/8.6.11) with ESMTP id GAA05717
          for <hackers@FreeBSD.org>; Wed, 30 Apr 1997 06:11:12 -0700 (PDT)
Message-Id: <199704301311.GAA05717@who.cdrom.com>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA012295806; Wed, 30 Apr 1997 23:10:06 +1000
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...)
To: msmith@atrad.adelaide.edu.au (Michael Smith)
Date: Wed, 30 Apr 1997 23:10:06 +1000 (EST)
Cc: bde@zeta.org.au, hackers@FreeBSD.org
In-Reply-To: <199704301243.WAA28705@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 30, 97 10:13:16 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 Michael Smith, sie said:
> 
> Darren Reed stands accused of saying:
> > > 
> > > _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.
> 
> This is debatable.
> 
> > Why ?  Why do we need to change something that already works ?
> 
> The issue is that in 2.1.x, devsw entries were members of a
> compile-time-defined array.  This is the traditional *nix edit-conf.c
> approach.
> 
> 2.2 builds the devsw tables at link time using linker sets, and as
> such the devsw arrays are now arrays of pointers to devsw structures.
> This is a huge plus, in that one no longer has to mung the stuff in
> conf.c in order to add a new driver.
> 
> Bruce's argument is that drivers should do their own management of
> devsw entries.  I'm inclined to disagree, especially as there is no
> API for doing this; you are expected to grovel directly.

I'd argue that if the kernel is doing it itself, and the table for *devsw
is dynamic, then it is outside the scope of an ordinary driver to be
making changes.  But maybe that is going a bit far...

I had a read of kern_lkm.c for 2.2 and the cdevsw_add() was written to
work how IP Filter uses it.  That is, add an entry if there isn't one
there or replace if there is.  This has preserved the old behaviour.

Whether or not the *devsw created get's freed (and pointer restored to
what it was previously) or a null copy is coppied over, I don't care,
so long as it is all handled internally to the LKM code.

I can't see that there should be an API for this either - it should be
the LKM code's job to maintain the table correctly.

> It's probably worth checking with the last people that had their hands
> dirty in the LKM stuff.  Rest assured though that the idea here is not
> to make any 'ad hoc' changes. 8)
[...]
> If you have a genuine beef with something that's proposed, make some
> noise about it.  Chances are that if you get involved in the design
> phase, you can save yourself some work instead 8)

Noise like the comments I made come from also having to deal with include
file changes (which don't appear to do anything worthwhile except create
compatibility problems).

Darren