Path: utzoo!attcan!uunet!husc6!mit-eddie!apollo!gaz
From: gaz@apollo.COM (Gary Zaidenweber)
Newsgroups: comp.os.minix
Subject: Re: Request for advice on PS/2 problems
Message-ID: <4113d7ab.ce45@apollo.COM>
Date: 25 Jan 89 15:53:00 GMT
References: <1944@ast.cs.vu.nl>
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 66

From article <1944@ast.cs.vu.nl>, by ast@cs.vu.nl (Andy Tanenbaum):
> Steve Ackerman has reported getting MINIX to boot on the PS/2 Model 80.
> Good work!  However, we are not really done yet.  I have to figure out
> how to deal with level-triggered interrupts in a reasonable way.  This
> message solicits suggestions.  Please post them, since 10K heads are
> better than 1.
> 
> MINIX, like all other message passing operating systems, does not do much
> in its interrupt routines.  It just sends a message and returns from the
> interrupt.  This means that after a floppy disk interrupt, the interrupt
> line would normally still be asserted.  However, to shut off the 8259A
> interrupt controller, on line 1888, we order it to shut up.  On the PS/2
> this doesn't work.  We have to actually talk to the device.  It is
> probably unwise to do this inside the interupt() function.  This means
> we have to move line 1888 to each device driver and do it there.  Unpleasant
> but possible.

In my opinion, level-triggered interrupts are far preferable to edge-triggered
ones. One approach might be to rethink the definition of "does not do much in
its interrupt routines" and the explicit and implicit content of messages. I'm
sorry that I haven't looked at the code, but I have both designed and coded
drivers for many types of network devices in a multitasking OS.
> 
> However, things are worse than this.  If we delete line 1888 and move it
> to the device drivers, when the interrupt routine is finished, we will get
> another interrupt.  To prevent this, Steve diddled the 8259A's interrupt
> mask around line 1888.  Double ugly.

Again, my opinion, the interrupt dispatcher should be returned to by the
interrupt routine after its execution and the dispatcher will diddle such
machine-dependent hardware as the 8259A. It knows which routine was dispatched.
Well-designed controllers should be able to queue level-triggered interrupts.
> 
> My question is: does anybody see a better and cleaner way to do this?
> I don't especially want the code around line 1888 having to figure out
> which of the 8259A's to diddle, and which bit, etc.  For the floppy it
> may not be too bad, but for serial I/O, networking, etc, it will make
> things more complicated and error prone in a sensitive area.  On the other
> hand, I don't want a major redesign of things.  I think the original
> design is fairly simple and don't want to muck it up because of the way
> the PS/2 does things.) I'd also like to minimize the amount of code of the sort
My above suggestions, unfortunately, do add a bit of complexity with the payoff
of "nearly infinite :-)" flexibility.
> 
> if (ps)				/* Models 25 - 80 */
> if (mca) ...			/* microchannel architectures only */
> if (ps && mca == FALSE) ...	/* Models 25 and 30 */
> etc.
> 
> Hardware types, get out your thinking caps.
> 
> Another point, I am still trying to figure out exactly how to tell if 
> a machine is (1) PS/2 and (2) Microchannel.  Several people have pointed
> out that INT 15 is supposed to tell you, but I can't find that in my
> (PC) BIOS manual.  Maybe it is something new.  Could some kind soul please
> write a little piece of code that can be added to klib88.s making the
> call to int15, and then write the C code for using this call to set the
> variables ps and mca in such a way that it works on PC, XT, AT, and PS/2
> (preferably without including a complete expert system in there).  Thanks.
> 
> Andy Tanenbaum (ast@cs.vu.nl)
-- 
Gary Zaidenweber        |   It's nice to know that if someone gets
UUCP:   umix!apollo!gaz |   caught shredding the constitution, that
ARPA:   gaz@apollo.COM  |   you can at least charge him with littering.
AT&T:   +1 508 256 6600 |    -- Jay Leno