Date: Sun, 24 Sep 1995 16:21:32 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hm@altona.hamburg.com Cc: dennis@etinc.com, hackers@FreeBSD.ORG Subject: Re: LKM: how to fiddle in interrupt routine ptrs ? Message-ID: <199509242321.QAA04102@phaeton.artisoft.com> In-Reply-To: <m0swyfW-000013C@ernie.altona.hamburg.com> from "Hellmuth Michaelis" at Sep 24, 95 10:33:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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). > > 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. I agree that there should be a fixed size interrupt table. But I think there are ISA/EISA/PCI issues to be worked out for this to happen. As in the previous discussion of PCI with CGD, I think that the idea of seperating the mapping and the bridging will have to be worked out before this is possible. As more and more PCI machines are produced, it's only a matter of time before a "pure PCI" box is built, or a PCI box that uses ISA->PCI bridgning to get it's ISA support. This is a problem that already faces Motorolla PPC Ultra 603/604 and DEC Alpha 21066/21068 machines, which are native PCI and only support ISA through bridging. A table of vector lists for shared interrupts is a move in the right direction on this. > Also, it is unclear what should happen with the probe and attach routines. I think they need to be wrappered so that interrupts on devices on a shared interrupt can be disabled during a probe to avoid false positives. There's still problems with devices that have destructive probes, and the reading of config information given the I/O window (like you can do on WD and NE2000 cards, for instance) needs to be worked over to have a uniform probe/attach/detach interface. The 3COM "Plug-N-Play" features work similarly. Perhaps it's worth a look at the MS "Plug-N-Play" specification from their FTP site? I'm not sure the information in the SDK/DDK packages can be used without violation of licensing. 8-(. Now that MS owns 20% or more of UNIX (I'm not sure exactly how much of SCO they own; it was 20% around 1990), it could get real sticky. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509242321.QAA04102>