Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven!umd5!cgs
From: cgs@umd5.umd.edu (Chris G. Sylvain)
Newsgroups: comp.os.minix
Subject: Re: Dumb Questions -- IBM Minix
Message-ID: <7668@umd5.umd.edu>
Date: 4 Dec 90 21:12:36 GMT
References: <10150@bunny.GTE.COM> <1990Dec4.151849.28931@dsuvax.uucp>
Reply-To: cgs@umd5.umd.edu (Chris G. Sylvain)
Organization: University of Maryland, College Park
Lines: 34

In article <1990Dec4.151849.28931@dsuvax.uucp> ghelmer@dsuvax.uucp (Guy Helmer) writes:
>In <10150@bunny.GTE.COM> seb3@GTE.COM (Steve Belczyk) writes:
>
>
>>   [..] Is there any way to add two more, on COM3 and COM4?
>
>Not really. [..] It would be quite a challenge to change the rs232 driver
>to handle shared interrupt lines, and the additional interrupt service
>overhead would eat up even more CPU cycles than it does now :-(

Sorry Guy, but I think it would be much less of a deal than you indicate.
All the rs232 driver needs to do is read two IIR (interrupt identification
registers) instead of one.

Both IIRs may indicate an interrupt pending, in which case you receive
(or transmit) two characters for the price of one interrupt.
Is that really so terrible?

Worst valid case is when the interrupt was not posted by the first IIR read.
The second is read instead, and a different tty minor number is used to move
a character (or begin moving a buffer-full). I'm not convinced that an
unacceptable amount of byte shoveling is needed to read a second IIR and
stuff a byte (or yank a byte) from the appropriate tty_nr->buffer.

Worst case is when neither IIR shows a pending interrupt. The cost of
supporting the shared interrupt was the (small) time required to read the
second IIR.

Thoughts anyone? (or am I about to be flamed?)
-- 
--==---==---==--
Mome: Short for _from home_ - meaning you've lost your way
--   ARPA: cgs@umd5.UMD.EDU     BITNET: cgs%umd5@umd2   --
--   UUCP: ..!uunet!umd5.umd.edu!cgs                    --