Interrupt Descriptions

[John Baldwin]

On Thursday 01 October 2009 4:41:19 pm Bruce Evans wrote:
> 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.

Some of this simplification can actually be undone now.  We can probably wait 
to allocate an interrupt event for x86 interrupts until the first interrupt 
handler is installed and defer allocating intrcnt's until then.  There were 
reasons why we always allocated ithreads back before interrupt events that I 
don't recall now.  I'm also not sure we really need separate stray interrupt 
counts either at this point as stray interrupts are extremely rare.  A single 
stray counter might suffice at this point.

However, all of this is still orthogonal to interrupt description strings.

> 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.

I think this mostly serves to prove the point that the existing design is
tailored to static configurations, not dynamic ones.

-- 
John Baldwin