From owner-freebsd-hackers  Wed Apr 30 07:08:10 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id HAA27803
          for hackers-outgoing; Wed, 30 Apr 1997 07:08:10 -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 HAA27718
          for <hackers@FreeBSD.org>; Wed, 30 Apr 1997 07:07:05 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id AAA27241; Thu, 1 May 1997 00:02:41 +1000
Date: Thu, 1 May 1997 00:02:41 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199704301402.AAA27241@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: bde@zeta.org.au, hackers@FreeBSD.org
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>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.

Actually, it builds tables of functions at link time using linker
sets.  The functions are then used early at runtime to build the
devsw tables.  This implementation was expedient 17 months ago and
bad 16 months ago.

>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.

The drivers either have to build tables of pointers to devsw's for some
higher layer to use, or register the pointers directly.  Doing it directly
is more flexible although it takes a few bytes more space at runtime.
There are (BAD) interface functions bdevsw_add(), cdevsw_add() and
bdevsw_add_generic().

Bruce