Interrupt Descriptions

Bruce Evans brde at optusnet.com.au
Thu Oct 1 20:41:22 UTC 2009


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


More information about the freebsd-arch mailing list