Subject: Re: malloc above splimp
To: Niklas Hallqvist <>
From: None <>
List: amiga-dev
Date: 08/31/1994 12:39:41
> I'm getting successful with the GoldenGate and the com driver.  Now I
> can actually use it for logging in and dialout.  However at high speeds
> there can occur some problems, one of them being malloc messing up its
> internal state.  After some investigation I found that malloc does
> splimp which is spl3 in the amiga port.  As I use si_addcallback at
> spl6 this can (and will) result in bad behaviour.  This morning I saw
> the following call chain (from memory, excuse me if I don't remember
> the exact names):

The point of si_callbacks as far as I saw was that you wanted to 
delay processing of a certain interrupt code to lower priority.  I
guess I need to here why your callbacks need splhigh() protection
(if I understand what your requesting).

If its do to interrupts from the IO bridge, is it possible to use
interrupt level 2 instead?  This is the level that IO should take
place at not level 6.  Interrupt level 6 is reserved for system clocks
and other things (?) of such high importance.

Changing splimp() to splhigh() whould have many unwanted side-effects
I would think.  I don't like the idea at all.  For example spltty()
would be interrupted by a level 6 interrupt to what would you do for that?

I have run into a similar problem however with the ASDG LAN Rover.
My board interrupts only at level 6.  To solve this I will use an
si_callback that processes most of the interrupt.  With the actual
level 6 handler just clearing the interrupt and saving it in a software
register for processing by the call back.  This is messy but its really
the only way to handle such problems.

> using a callback pool instead.  This would both be faster than malloc
> and an easy fix as it will only have local influences.  The drawback
> is that it has to be a static limit of callbacks, but as the descriptors

Using malloc is nice in that it doesn't waste any memory and it can
accomadte many requests all made at `once'.  I think we should keep it.

> On a related topic, we need to redo the interrupt system a bit in order
> to have drivers being LKMs.  We must have a interrupt handling
> registration during attachment like the i386 port.  I'm willing to
> write this if Chris says go.

I was going to write this and put it in after the release.  If you can wait
I would appreciate it.  If you need it now however go ahead.