From owner-freebsd-hackers  Sun Sep 24 08:31:50 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id IAA01466
          for hackers-outgoing; Sun, 24 Sep 1995 08:31:50 -0700
Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA01459
          for <hackers@freebsd.org>; Sun, 24 Sep 1995 08:31:47 -0700
Received: from et.htp.com (et.htp.com [199.171.4.228]) by etinc.com (8.6.11/8.6.9) with SMTP id LAA27363 for <hackers@freebsd.org>; Sun, 24 Sep 1995 11:38:44 -0400
Date: Sun, 24 Sep 1995 11:38:44 -0400
Message-Id: <199509241538.LAA27363@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hackers@freebsd.org
From: dennis@etinc.com (dennis)
Subject: Re: LKM: how to fiddle in interrupt routine ptrs ?
Sender: owner-hackers@freebsd.org
Precedence: bulk

>>Is there a generic or recommended way or example of installing a device's
>>interrupt routine at mod-loading a device driver LKM time ?
>
>See pcibus.c:pcibus_ihandler_attach/detach.
>
>There are some minor problems with these routines:
>
>- the `func' arg should already have the correct type (inthand2_t).
>- `deviced??' should be spelled `device_id??'
>- it isn't possible to give a correect device_id.  0 is for clkintr.
>  The device_id is only used for counting interrupts.  To fix this
>  you would have to expand the string table in vector.s and edit it.
>- 1ul should be 1u.
>- update_intr_masks() and INTREN() and INTRDIS() may need to be called
>  at a high ipl or with interrupts disabled.  The whole routines may
>  need to be called at a high ipl or with interrupts disablied.
>- INTRDIS() in pci_ihandler_detach() isn't right if several devices
>  are sharing the interrupt.
>- INTRDIS() in pci_ihandler_detach() isn't right if the unregister_intr()
>  fails.
>
>>Does one have to copy the old isa_devtab_xxx[], expand it with an entry
>>and exchange it with a new one ?
>
>That might work.  You would have to edit the interrupt name string table
>too.  It would be better to supply a dummy driver and replace that,
>
>>What is the way to tell the driver at mod-load time it's IRQ and i/o addr ?
>
>There is no way.  You could use the values from the dummy driver.  These
>values can be handled using standard methods (config, userconfig, dset).
>
This method is not good and requires some thought. In the big picture, one of 
the most useful purposes of modules is the ability to add devices without having
to recompile the kernel. If I have to install dummy drivers I've lost my
need to use
modules. If the sole purpose of modules is to keep the kernel small.....then
OK,  
but its a pretty short-sighted approach. Linux modules are nice because you
can send
someone who doesn't know how to to build a kernel a complete, complex subsystem
and they can just pop it in. It expands the marketability of the module
product as well
as the O/S, because small, generic kernels can be expanded dynamically
without having
to know what you're doing.

Dennis