Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Mar 1995 05:17:46 -0500 (EST)
From:      Peter Dufault <dufault@hda.com>
To:        darrenr@vitruvius.arbld.unimelb.edu.au (Darren Reed)
Cc:        freebsd-hackers@freefall.cdrom.com
Subject:   Re: Configuring driver added via LKM
Message-ID:  <199503291017.FAA03749@hda.com>
In-Reply-To: <199503290905.TAA03025@vitruvius.arbld.unimelb.EDU.AU> from "Darren Reed" at Mar 29, 95 07:05:46 pm

next in thread | previous in thread | raw e-mail | index | archive | help
(I'm sending this back to the list.  Darren and I discussed it
off line a bit)

(Darren Reed)
> > > You have to unload via modunload, and you should set some function up
> > > in your LKM to serve VD_UNLOAD.  You'll need to do the rest yourself -
> > > shouldn't be too hard to keep it private to your driver.
> > 
(Me)
> > I don't want to put any special code in the driver.  The driver
> > should be identical whether it is being loaded or config'd in the
> > kernel, with no special LKM cruft.
> > 
> > If I add warning calls into the driver ("You are about to be shut
> > down") there is no problem.  I'm asking around before I go and
> > start to mod isa.c to support what I want to do, in case I'm missing
> > something.
> > 
> > In isa/isa.c you won't find a good hook for warning a driver that
> > it is going to be shut down.  It is halfway there in the "reconfig"
> > code, but not completely there.
> 
> No, you put it all in the LKM specific code...
> 
> ...that's what put the driver there, and it should be responsible for
> taking the driver out.  For example, you'd have VD_UNLOAD nullop the
> read/write/etc driver hooks or point them to something which returned
> the right error until it could fully remove it.  I'm not talking about
> chaning isa.c or anything else, just writing a non-trivial unload
> handler for the LKM.

No, I disagree.  That logic shouldn't be LKM code that isn't present
in a config'd driver, it should be a standard driver entry point
similar to probe and attach.

I would probably (incorrectly but expeditiously in that it isn't
really an isa problem) implement this by changing the definition
of isa_driver to include "goaway(struct isa_device *isdp)", but I
think that the "goaway" entry point in "kern_devconf" is supposed
to do this.

In isa.c I would add something like:

isa_install_driver(struct isa_device *isdp, u_int *mp);
isa_remove_driver(struct isa_device *isdp, u_int *mp);

"isa_install_driver" will pretty much just call config_isa_dev_c.

"isa_remove_driver" will call the driver goaway entry point, and
if it returns 0, removes the isr if it was specified.  The goaway
entry point will stop all activity if it can, deregister itself
from kern_devconf, and so on.  At that point you can safely unload
the LKM.

If you had these facilities you could pretty quickly come up with
a utility that would install a driver's .o file directly without
any LKM glue.  That would be nice for testing drivers.

What I haven't figured out is how this is supposed to play with
kern_devconf or with the reconfig code already in isa.c supporting
removable devices.  After all, this isn't isa specific and I think
that kern_devconf is trying to address these issues.

Peter

-- 
Peter Dufault               Real Time Machine Control and Simulation
HD Associates, Inc.         Voice: 508 433 6936
dufault@hda.com             Fax:   508 433 5267



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503291017.FAA03749>