Date: Sun, 24 Sep 1995 11:38:44 -0400 From: dennis@etinc.com (dennis) To: hackers@freebsd.org Subject: Re: LKM: how to fiddle in interrupt routine ptrs ? Message-ID: <199509241538.LAA27363@etinc.com>
next in thread | raw e-mail | index | archive | help
>>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509241538.LAA27363>