Re: user-written interrupt handlers

[miff@asharak.apana.org.au (michael smith)]

In <9403091128.AA17668@pirol.techfak.uni-bielefeld.de> you wrote :

>Juergen Lock writes:

>> btw anyone using the TT's SCC DMA yet? its too bad mega STe don't have it :)
>> (and have all this SCC problems too.)
>
> Regarding that it has a 3 byte fifo one should think it would be worth a
>closer look at, so to say: Well I've missed one interrupt... hmmm... never
>mind, next time, I'll fetch two chars. You could start calculating a
>probability for missing three interrupts after another...
>
> But then: What's about the MSTE problems with it? Have heard about them,
>but nothing concrete. And what about the falcon? Have only heard it doesn't
>use a MFP for serial communication. Don't know what it uses.

AFAIK (from the schematics 8) there is an MFP in there, but the serial lines
don't go anywhere (which is a pain, there are some free drivers in there too
8( )

The falcon serial interface is run on an SCC - I can't tell whether this 
is arranged as with the SCC in the TT.

> Looks like there'll never be a kernel with new device drivers, because
>you would have to write three of them for all existing hardware... :-(

Hmm, more scope for loadable ones I think - in fact, I am _sure_.  Myself,
I'd like to see all but the TOSFS driver loaded at startup rather than linked
in.  (I know this may be unreasonable, I haven't looked at it yet).
Then the kernel should go looking for the appropriate drivers for the
current hardware, and load any user-supplied ones. (you'd probably do it
with a small tree structure :

\mint
\mint\system
\mint\drivers

or similar.  Who knows - it would be nice.  So would AiNA (you guess 8)

>TeSche


--
--
mike smith : silicon grease monkey  | If you think it can't be done, |
miff@asharak.apana.org.au           | it means you don't have enough |
miff@apanix.apana.org.au            | money in your budget.          |