Interrupt Descriptions

[Bruce Evans]

On Fri, 2 Oct 2009, John Baldwin wrote:

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

No, string spaces are ideal for dynamic management of small collections
of strings and for larger collections of strings that are accessed
mostly sequentially.  They are essentially the same as a text file.
There is no better data structure for a text file than to concatenate
all the lines together.  Sometimes you want non-sequential access for
text files, e.g., for tail -n and in editors, but this is rare and
then you can build random-access substructures as needed.  Collections
of interrupt names are both small and accessed mostly sequentially.

Bruce