MESSAGE
| DATE | 2015-01-29 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [LIU Comp Sci] Operating System Interupts
|
From owner-learn-outgoing-at-mrbrklyn.com Thu Jan 29 22:02:51 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 5FE1F1612E4; Thu, 29 Jan 2015 22:02:51 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 4AF501612E7; Thu, 29 Jan 2015 22:02:51 -0500 (EST)
Delivered-To: learn-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id CB1891612E4
for ; Thu, 29 Jan 2015 22:02:50 -0500 (EST)
Received: from [10.0.0.19] (unknown [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTPSA id 72AFC1336F;
Thu, 29 Jan 2015 22:02:50 -0500 (EST)
Message-ID: <54CAF45A.5020708-at-panix.com>
Date: Thu, 29 Jan 2015 22:02:50 -0500
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: learn-at-nylxs.com, Samir Iabbassen
Subject: Re: [LIU Comp Sci] Operating System Interupts
References: <54CAAE57.1030900-at-panix.com>
In-Reply-To: <54CAAE57.1030900-at-panix.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
Here are some responses from usenet....
Notice the repliers identification
Path: reader1.panix.com!panix!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: "Vince Coen"
Newsgroups: comp.os.linux.hardware
Subject: Re: Operating System Design
Date: Thu, 29 Jan 2015 22:29:53 +0000
Organization: A noiseless patient Spider
Lines: 62
Sender: "Vince Coen"
Message-ID: <1422570593-at-f1.n250.z2.fidonet.ftn>
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: mx02.eternal-september.org; posting-host="f32d0f4c669d02053c6f6758d3d26e68";
logging-data="5254"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX1/ap86OYeMnGxoZvJlSDnc6"
X-FTN-TID: MBSE-FIDO 1.0.4 (GNU/Linux-x86_64)
X-Newsreader: GoldED+/LNX 1.1.5 (Linux 3.14.27-server-1.mga4 CPU UNKNOWN)
X-FTN-Sender: Vince Coen
X-FTN-AREA: COMP.OS.LINUX.HARDWARE
Cancel-Lock: sha1:2ijq3jNH3J9UYSbcHYM8ehl32Jg=
X-FTN-CHRS: UTF-8 2
X-FTN-PATH: 250/1
X-FTN-SEEN-BY: 25/0 250/0 1 2 9 263/0
X-FTN-MSGID: 2:250/1-at-fidonet 54cab5e1
X-Origin-Newsgroups: comp.os.linux.hardware
X-FTN-PID: GED+LNX 1.1.5-b20120229
X-Comment-To: "ruben safir"
REPLY: reader1.panix.com f87ca9e3
X-FTN-TZUTC: 0000
Xref: panix comp.os.linux.hardware:364724
Hello ruben!
Lots of words to say that they IHR must be quick so minimum of code.
Likewise the routines themselves must also be fast to ensure that no data
is lost allowing for a secondary interrupt to occur etc.
Somewhere in my libary I have 2 books on OS design with one covering the
design and implementation of Minux (this one is worth reading) but the
other is a lot older and I used it when helping to develop VME for ICL in
the early 70's. Proved very helpfull in avioding various traps.
Must remember to dig it up and by memory written around 1969-1972.
Written and published in the USA.
Vince
Thursday January 29 2015 22:11, ruben safir wrote to All:
> I'm wondering if anyone has a background in operating system design.
> I'm taking a class is OS's and the text is
> OPERATING
> SYSTEM
> CONCEPTS
> ABRAHAM SILBERSCHATZ
> 9th edition, and it says something that is puzzling me
> "Interrupts are an important part of a computer architecture. Each
> computer design has its own interrupt mechanism, but several functions
> are common. The interrupt must transfer control to the appropriate
> interrupt service routine. The straightforward method for handling
> this transfer would be to invoke a generic routine to examine the
> interrupt information. The routine, in turn, would call the
> interrupt-specific handler. However, interrupts must be handled
> quickly"
> " Since only a predefined number of interrupts is possible, a table of
> pointers to interrupt routines can be used instead*** to provide the
> necessary speed. The interrupt routine is called indirectly through
> the table, with no intermediate routine needed. Generally, the table
> of pointers is stored in low memory (the first hundred or so
> locations). These locations hold the addresses of the interrupt
> service routines for the various devices. This array, or interrupt
> vector, of addresses is then indexed by a unique device number, given
> with the interrupt request, to provide the address of the interrupt
> service routine for the interrupting device. Operating systems as
> different as Windows and UNIX dispatch interrupts in this manner."
> *** Instead of what? Just because you have a table of pointers to
> routines doesn't change the need for a routine, a generic routine
> perhaps, from accessing that table.
> Ruben
Vince
On 01/29/2015 05:04 PM, Ruben Safir wrote:
> I just can figure out what this guy is say here. It doesn't make sense.
>
> "Interrupts are an important part of a computer architecture. Each computer
> design has its own interrupt mechanism, but several functions are common.
> The interrupt must transfer control to the appropriate interrupt service
> routine.
> The straightforward method for handling this transfer would be to invoke
> a generic routine to examine the interrupt information. The routine, in
> turn,
> would call the interrupt-specific handler. However, interrupts must be
> handled
> quickly
>
> " Since only a predefined number of interrupts is possible, a table of
> pointers to interrupt routines can be used instead*** to provide the
> necessary
> speed. The interrupt routine is called indirectly through the table, with no
> intermediate routine needed. Generally, the table of pointers is stored
> in low
> memory (the first hundred or so locations). These locations hold the
> addresses
> of the interrupt service routines for the various devices. This array,
> or interrupt
> vector, of addresses is then indexed by a unique device number, given with
> the interrupt request, to provide the address of the interrupt service
> routine for
> the interrupting device. Operating systems as different as Windows and UNIX
> dispatch interrupts in this manner."
>
>
> *** Instead of what? Just because you have a table of pointers to
> routines doesn't change the need for a routine, a generic routine
> perhaps, from accessing that table.
>
>
> Ruben
>
|
|
