From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] IRQs again... From: David Gordon Hogan MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 28 May 2002 00:56:35 -0400 Topicbox-Message-UUID: 9dab9490-eaca-11e9-9e20-41e7f4b1d025 > No. Sorry. There are good reasons for this and it ain't going to happen. > We've been over this ground quite a bit over the last 2 years. The OS has > a way better idea of what it needs, and once you start pulling in nonsense > like SMP and APIC and IO-APIC it gets very very messy. The odds that the > BIOS can get things set up right for the OS become vanishingly small. Yet somehow, most of the BIOSes we've seen do a pretty good job of it. I think it comes down to the BIOS being board-specific. You're trying to replace such a thing with a generic program (AFAICT), which I imagine to be much harder. Presumably you have some way of configuring it though...? > I'm still a little lost on how you plan to handle the hot plug thing. What > do you plan to do if the device is not there until after the OS boots? Or > goes away? do you reclaim the interrupt or not? Do you plan to callback to > the BIOS? We don't do callbacks either. Just divvy up the free IRQs amongst the various PCI interrupt lines on the south bridge. When a new device is inserted, consult the PCI routing table and the south bridge assignments to figure out its IRQ. Remember that PCI IRQs can be, and are often, shared. On many systems, most of the IRQs are soaked up by `legacy' devices, leaving 2 or 3 for PCI. Do you actually have a hot-swappable cPCI system, or is this all hypothetical? >> We've thought about what it would take to make Plan 9 >> do this instead, and generally reached the conclusion >> that it would be a Bad Thing. > > can you elaborate? > > I just don't agree, and neither (it seems) do the other open source OSes > out there. But I've been wrong lots of times so if you have a solid reason > I'm all ears. I think our main reason is that (we think) we've got better things to do. I've looked at Linux's approach, and it doesn't seem to be a real solution: as there is no way to be sure of what IRQs are in use by legacy devices, it just sort of guesses. Most of the time the BIOS has already allocated IRQs, if not to the device itself, at least to the interrupt lines (as controlled by the south bridge). So the `guessing' code probably isn't used all that often. But, by all means, don't let me stop you from adding hot swap support to the kernel :-)