Date: Mon, 27 Nov 2000 22:01:20 -0800 (PST) From: John Baldwin <jhb@FreeBSD.ORG> To: Greg Lehey <grog@lemis.com> Cc: smp@FreeBSD.ORG, Jake Burkholder <jburkhol@home.com> Subject: Re: BSD/OS interrupt code Message-ID: <200011280601.WAA36325@john.baldwin.cx> In-Reply-To: <20001128144803.C36542@echunga.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28-Nov-00 Greg Lehey wrote: > On Monday, 27 November 2000 at 10:33:05 -0800, John Baldwin wrote: >> >> On 26-Nov-00 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. >> >> Hmm. The best way to do this probably is to have stubs with psuedo-relocation >> information. I.e., have 1 stub interrupt handler template for each type (fast, >> threaded, fast apic, threaded apic, etc.), then have a "relocation" table on >> the side that specifies offsets in the code that should receive one of a number >> of things: vector number, vector address, etc. Alternatively, we could store >> all of that info in a struct (gee, we already do with intrhand :)) and just >> have the code always dereference a pointer to that struct and have the >> relocation entries simply point to places that that pointer should be written. >> Granted, on sparc this could get much uglier (based on my understanding of >> relocation address on sparc since an address can be formed across several >> instructions. Yuck.) > > I assume you're talking about doing this at run time, presumably from > a function like inthand_add. This is a nice, structured way to do > things. One of the parameters might be the type of interrupt, so > instead of three stubs for each possible interrupt, we'd only have > one. Why didn't we do that from the start? Because it's slower. No, > I haven't tried to prove this, but I'm pretty sure you'd have > difficulties getting it small enough. > > One alternative would be to really create the entire interrupt handler > stub in inthand_add. It's not as difficult as it probably sounds, but > in general I agree with Bruce that the saving is probably not worth > it. Doing this would be a pain as Chuck kindly pointed out. One not so difficult step that can be taken is to make the stubs smaller and have them use more code in common. For example, you could probably reduce the per-interrupt source portion of the stub to just 'pusha; mov $irq_num, %eax; jmp common_code;' in the x86 case. However, the savings wouldn't be but so great. Nevertheless, it's something I may play with at some point in time. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?200011280601.WAA36325>