Date: Sun, 26 Nov 2000 20:06:58 -0800 From: Peter Wemm <peter@netplex.com.au> To: Jake Burkholder <jburkhol@home.com> Cc: Greg Lehey <grog@lemis.com>, smp@FreeBSD.ORG Subject: Re: BSD/OS interrupt code Message-ID: <200011270406.eAR46wD45035@mobile.wemm.org> In-Reply-To: <20001127015006.5B7BDBA7A@io.yi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jake Burkholder wrote: > > On Sunday, 26 November 2000 at 14:07:49 -0800, Jake Burkholder wrote: > > > Hi, > > > > > > If anyone with access to the BSD/OS code is interested, I've written > > > a little program that runs their interrupt stub code generator in > > > userland. You can then abort(); and disassemble the stub from > > > the core dump to look at the code all in one piece. Makes it much > > > easier to follow. > > > > > > In case you haven't looked, their interrupt handlers are generated > > > by bcopy-ing various blocks of assembler code into an array at > > > runtime, and then poking in arguments and relocating branches. > > > > Interesting. I was wondering whether something similar would be a > > good idea. On the other hand, We don't waste much space by having > > multiple alternate stubs. What's your feeling? > > I suspect that it would be hard to do this for architectures > other than x86, which has a relatively simple instruction format. > > I also think that BSD/OS went a little too far with this, and > have produced code that is very difficult to understand, let > alone maintain. I think its cool what they did, I'm humbled > and amazed that they made it work, but I don't know that its > right for FreeBSD. I was looking at taking a shot at doing something like this a few days ago. While in .au I went through the leftovers of our old interrupt code and did a cleanup. I also made the APIC code support 32 hardware IRQ sources instead of the old 24 limit. The 24->32 IRQ change affected no less than 6 or 7 places where there are static tables. It is kind of a shame that we're still stuck with it given the large multi-pci bus systems we're running into these days with 32 or 48 hardware interrupt sources. The other reason for looking at this was for certain broken hardware that has IRQ sources connected *only* to the PIC (ie: the apic pin connection is missing). Right now, we cheat by using *one* pic source in auto-EOI mode and daisy-chaining it all to the APIC. This doesn't work if the PIC->APIC interlink is missing (as I believe it is on this box) or there are multiple PIC-only interrupt sources that we need (ie: timer0 and rtc). I dont have the actual hardware in my hands yet, but I have an awful feeling that it is going to require running the PIC *and* APIC at the same time, with different IDT vectors. The stub generation code might help keep down the cost of replicating another 16 sets of slow and fast interrupt handlers.. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011270406.eAR46wD45035>