From owner-freebsd-hackers  Thu Jan  2 21:27:05 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id VAA29800
          for hackers-outgoing; Thu, 2 Jan 1997 21:27:05 -0800 (PST)
Received: from calvino.alaska.net (root@calvino.alaska.net [206.149.65.3])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA29795
          for <hackers@freebsd.org>; Thu, 2 Jan 1997 21:27:03 -0800 (PST)
Received: from calvino.alaska.net (hmmm@calvino.alaska.net [206.149.65.3]) by calvino.alaska.net (8.8.0/8.7.3) with SMTP 
	id UAA04229 for <hackers@freebsd.org>; Thu, 2 Jan 1997 20:26:26 -0900 (AKST)
Date: Thu, 2 Jan 1997 20:26:26 -0900 (AKST)
From: hmmm <hmmm@alaska.net>
Reply-To: hmmm <hmmm@alaska.net>
To: freebsd-hackers <hackers@freebsd.org>
Subject: Re: Ints
In-Reply-To: <199701021134.WAA16141@genesis.atrad.adelaide.edu.au>
Message-ID: <Pine.GSO.3.93.970102194930.22753B-100000@calvino.alaska.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Thu, 2 Jan 1997, Michael Smith wrote:

> Please don't go inventing your own terminology in order to prove
> yourself "right".  If you are responding to an interrupt, you are not
> "polling" as such.

hehe!  i'm not!  interrupts - in a pure form - implies random activity.
if i'm using interrupts under polled conditions - the interrupts are timed
- not random - how else can i distinguish ???  that was the whole point of
my question ...
 
> > MAY change - or DOES change ?  is it usually a circuit outside of CPU
> > concerns?  do INT status flags change EXACTLY as the condition is removed?
> 
> "may" change.  If you really want the low-down on how much UART
> implementations vary, search the FreeBSD mailing list archives for
> mention of a program called COMTEST in a message from Frank Durda.
> Basically, there is very little that you can actually count on.

thanks - i'll check it out .. :)
 
> inactive to active.  It is the processor's responsibility to
> manipulate the peripheral so that the input goes inactive again.  If
> it fails to do so, there will be no more interrupts from it.  Finito.

hehe!  well - if things are so screwed up - you shouldn't be too angry
with me for being at a loss for the facts.  i couldn't find the "details"
in data sheets.  i thought things were more sane.

i sure appreciate all the time you took to assist me!