Date: Mon, 25 Sep 1995 17:20:04 +1000 From: Bruce Evans <bde@zeta.org.au> To: dennis@etinc.com, hm@altona.hamburg.com Cc: hackers@freebsd.org Subject: Re: LKM: how to fiddle in interrupt routine ptrs ? Message-ID: <199509250720.RAA02192@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >- 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. >It seems to be almost impossible to give it, NR_DEVICES is a constant >computed by config, it must be made a variable. Allocate some spare devices in vector.s. Note that until you change all clients of intrcnt[] and intrnames[] (in particular, systat and vmstat), the interrupt arrays have to be statically allocated. Also, once allocated, the interrupt names and counts must be preserved until the system is rebooted (the interrupt names are actually device+ interrupt names and it is possible for the same interrupt to be attached to different devices at different times). >> >>What is the way to tell the driver at mod-load time it's IRQ and i/o addr ? >> > >> >There is no way. >There should be a way to make this usable. You get to implement new things if you write the first modloadable driver :-). Actually, the question is wrong. Modload shouldn't do any more than load and attach the driver. Once it is loaded you can send ioctls to it. There probably needs to be a non-physical control device that the ioctls can be sent to to tell the driver where the physical devices are. >> 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. The dummy drivers are a temporary kludge. The system could supply a limited number of dummy drivers. E.g., until devfs exists, major device numbers must be reserved and there is little extra overhead for reserving a dummy device for each reserved major. >It seems that some work is necessary on the device driver lkm model to make >it fully work: there must be a way to specify a device driver interrupt >handler, the hardware interrupt to use and a i/o and memory address (range). To make it work at all :-). >For me it looks like certain constants are computed at compile time rather >than runtime, and depending on this constants some kernel tables are sized. >This has to change, there should be a fixed size table (filled with dummies >for nonexistent devices) for all possible interrupts which will be filled >with the respective entries by mod-loading a driver. A fixed size table would be worse than what I suggested above: a variable user-configured table (the same as now) with `n' (>= 0) user- configured dummy entries. When a new driver is loaded it takes one of the free dummy entries just like it would if everything was fully dynamic; the case n == 0 must be handled the same as if some dynamically allocated resource is exhausted. >Also, it is unclear what should happen with the probe and attach routines. They will have to be much more careful to run in multi-user mode. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509250720.RAA02192>