Date: Wed, 30 Apr 1997 13:02:33 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: bde@zeta.org.au (Bruce Evans) Cc: hackers@freebsd.org Subject: Unloading LKMs (was Re: A Desparate Plea for Help...) Message-ID: <199704300332.NAA25320@genesis.atrad.adelaide.edu.au> In-Reply-To: <199704291010.UAA30468@godzilla.zeta.org.au> from Bruce Evans at "Apr 29, 97 08:10:18 pm"
index | next in thread | previous in thread | raw e-mail
Bruce Evans stands accused of saying:
> >Please keep me up to date on the results of your LKM-related tests. If
> >it turns out that there's a problem with unloading LKMs leaving occupied
> >but invalid devsw entries around we'd better fix it 8)
>
> Er, AFAIK unloading LKM drivers is broken in all cases. It certainly
> doesn't work for either of the officially supported LKM cdevs (joy
> and qcam). Unloading either of these and then attempting to opening
> the nonexistent device gives precisely the trap at _spec_open+0x6e that
> Simon reported (the devsw entry is not affected by unloading and points
> to garbage). Unloading followed by reloading obviously can't work,
> because the driver only initializes the devsw once.
Um, the driver initialises the devsw on every load, does it not? eg:
static int
qcam_load (struct lkm_table *lkmtp, int cmd)
{
if (qcam_probe(&qcam_mod_dev)) {
qcam_attach(&qcam_mod_dev);
qcam_drvinit(NULL); /* XXX this shouldn't NEED to be here
* the LKM code should be doing this
* for us! */
...
Still, I take your point about the cdevsw not being updated. I can't see
a clean way of doing this, either.
Doug R., how do you approach this in your New Module Structure? (No, I
haven't had time to read it yet 8( 8( 8( )
> Bruce
--
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704300332.NAA25320>