Subject: Re: malloc above splimp
To: Niklas Hallqvist <email@example.com>
From: None <firstname.lastname@example.org>
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.