Date: Fri, 2 Oct 2009 06:41:19 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org, Andriy Gapon <avg@icyb.net.ua> Subject: Re: Interrupt Descriptions Message-ID: <20091002053705.F21979@delplex.bde.org> In-Reply-To: <200910011412.31250.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> <200910010953.33838.jhb@freebsd.org> <20091002031720.J21519@delplex.bde.org> <200910011412.31250.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 1 Oct 2009, John Baldwin wrote: > On Thursday 01 October 2009 1:54:15 pm Bruce Evans wrote: >> >> The design has few limits. My old implementation had no limits on >> name lengths.... > > I consider having to rebuild the entire namespace when changing one name > a design limitation. I think it worked fine when you had machines without > hotplug hardware (or drivers) where the set of interrupts in use was > essentially built once during boot and static thereafter. Those probably didn't have anything as sophisticated as building it at boot time. In 4.4BSD-Lite2 it is just hard-coded into locore for hp300, sparc, luna64 and pmax, while for news3400 it is partially declared but not defined. It is missing even declarations for all other arches including i386, and pmax has a comment saying that the counters aren't used (perhaps they aren't used for any arch). I fixed this for i386. > However, that > is no longer the machines we have. Who cares if you have to rebuild the entire namespace occasionally. Any sort of dynamic allocation would need to rebuild it to extend it. String spaces are very easy to expand since they don't have any internal pointers and shouldn't have many external ones. Anyway, the design doesn't require rebuilding the namespace for all changes. My old implementation usually adds to the end of the string space using statically allocated space. There are external pointers that keep the names indexed consistently with the counters. New interrupts normally get a new slot in intrcnt[]. Old slots are intentionally not reused, except by devices with the same interrupt name. They preserve the names and interrupt counts of previously attached devices. Now, I think the intrcnt[] index is identical with the interrupt number, and old driver names are lost and old interrupt counts are merged (zeroed?) when a slot is reused. The old implementation also handles sparsely allocated interrupt numbers (which are just starting to become common) nicely without sparsely allocating all the tables. Now the tables use sparse allocation for an enormous number of slots. There seem to be 256 slots for non-MSI and another 512 for MSI giving a basic 768. This is then doubled to give slots for stray interrupts, and there are a few special-purpose slots, giving a total of a little more than 1536. This gives a string space size of about 32K. To simplify the implementation, the space for MSI and several APICs is allocated unconditionally. Here is the 4.4BSD-Lite2 code for hp300: % .globl _intrcnt,_eintrcnt,_intrnames,_eintrnames % _intrnames: % .asciz "spur" % .asciz "hil" % .asciz "lev2" % .asciz "lev3" % .asciz "lev4" % .asciz "lev5" % .asciz "dma" % .asciz "clock" % .asciz "statclock" % .asciz "nmi" % _eintrnames: % .even % _intrcnt: % .long 0,0,0,0,0,0,0,0,0,0 % _eintrcnt: This takes 53 bytes (plus 1 or 3 for padding) for the string space. Most machines still need about 53 bytes for the string space (don't waste slots to count or name stray interrupts separately). These 53 bytes can be built and processed by userland on every sysctl much faster than the 32K of mostly-unused bytes can even be copied out. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091002053705.F21979>